From owner-svn-doc-all@FreeBSD.ORG Thu Apr 18 13:58:38 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D17BFA5A; Thu, 18 Apr 2013 13:58:38 +0000 (UTC) (envelope-from issyl0@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id C2AD48B; Thu, 18 Apr 2013 13:58:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r3IDwcGo073267; Thu, 18 Apr 2013 13:58:38 GMT (envelope-from issyl0@svn.freebsd.org) Received: (from issyl0@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r3IDwbrG073259; Thu, 18 Apr 2013 13:58:37 GMT (envelope-from issyl0@svn.freebsd.org) Message-Id: <201304181358.r3IDwbrG073259@svn.freebsd.org> From: Isabell Long Date: Thu, 18 Apr 2013 13:58:37 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r41455 - in head: en_US.ISO8859-1/htdocs/security share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 13:58:38 -0000 Author: issyl0 Date: Thu Apr 18 13:58:37 2013 New Revision: 41455 URL: http://svnweb.freebsd.org/changeset/doc/41455 Log: Start reorganising the security website pages: - State the easiest way for concerned users to update their system on the main page. - Move information about reporting vulnerabilities to a separate page as end users who just want to know how to patch their systems will not want to be bombarded with technical stuff about reporting and privacy. - The list of unsupported FreeBSD releases was too long to be on the main page, so move it out onto its own page. - Move some of the table of contents items non-essential to end users into the side navigation menu. (Further changes will be incremental.) Approved by: so (des) Added: head/en_US.ISO8859-1/htdocs/security/reporting.xml (contents, props changed) head/en_US.ISO8859-1/htdocs/security/unsupported.xml (contents, props changed) Modified: head/en_US.ISO8859-1/htdocs/security/Makefile head/en_US.ISO8859-1/htdocs/security/security.xml head/share/xml/navibar.ent Modified: head/en_US.ISO8859-1/htdocs/security/Makefile ============================================================================== --- head/en_US.ISO8859-1/htdocs/security/Makefile Thu Apr 18 13:44:42 2013 (r41454) +++ head/en_US.ISO8859-1/htdocs/security/Makefile Thu Apr 18 13:58:37 2013 (r41455) @@ -15,6 +15,8 @@ DOCS= charter.xml DOCS+= security.xml DOCS+= advisories.xml DOCS+= notices.xml +DOCS+= reporting.xml +DOCS+= unsupported.xml advisories.xml: advisories.html.inc Added: head/en_US.ISO8859-1/htdocs/security/reporting.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/en_US.ISO8859-1/htdocs/security/reporting.xml Thu Apr 18 13:58:37 2013 (r41455) @@ -0,0 +1,170 @@ + + +]> + + + + + &title; + + $FreeBSD$ + + + + +

Table of contents

+ + + + +

How and where to report a FreeBSD security issue

+ +

All FreeBSD security issues should be reported to the FreeBSD Security Team + or, if a higher level of confidentiality is required, PGP + encrypted to the Security Officer + Team using the Security + Officer PGP key. All reports should at least contain:

+ +
    +
  • A description of the vulnerability.
  • +
  • What versions of FreeBSD seem to be affected if possible.
  • +
  • Any plausible workaround.
  • +
  • Example code if possible.
  • +
+ +

After this information has been reported the Security Officer + or a Security Team delegate will get back to you.

+ +

Spam filters

+ +

Due to high volume of spam the main security contact mail + addresses are subject to spam filtering. If you cannot contact + the FreeBSD Security Officers or Security Team due to spam filters + (or suspect your mail has been filtered), please send mail to + security-officer-XXXX@FreeBSD.org with + XXXX replaced with 3432 instead of the normal + addresses. Note that this address will be changed periodically so + check back here for the latest address. Mails to this address + will go to the FreeBSD Security Officer Team.

+ + +

The FreeBSD Security Officer Team and the FreeBSD Security Team

+ +

In order that the FreeBSD Project may respond to vulnerability + reports in a timely manner, emails sent to the <security-officer@FreeBSD.org> + mail alias are currently delivered to the following people:

+ + + + + + + + + + + + + + + + + + + + + + +
&a.des; <des@FreeBSD.org>Security Officer
&a.delphij; <delphij@FreeBSD.org>Deputy Security Officer
&a.simon; <simon@FreeBSD.org>Security Officer Emeritus
&a.cperciva; <cperciva@FreeBSD.org>Security Officer Emeritus
&a.rwatson; <rwatson@FreeBSD.org>Release Engineering liaison,
+ TrustedBSD Project liaison, system security architecture expert
+ +

The Security Officer is supported by the FreeBSD Security + Team, <secteam@FreeBSD.org>, + a small group of committers vetted by the Security Officer.

+ + +

Information handling policies

+ +

As a general policy, the FreeBSD Security Officer favors full + disclosure of vulnerability information after a reasonable delay + to permit safe analysis and correction of a vulnerability, as well + as appropriate testing of the correction, and appropriate + coordination with other affected parties.

+ +

The Security Officer will notify one or more of the + FreeBSD Cluster Admins of + vulnerabilities that put the FreeBSD Project's resources under + immediate danger.

+ +

The Security Officer may bring additional FreeBSD developers or + outside developers into discussion of a submitted security + vulnerability if their expertise is required to fully understand + or correct the problem. Appropriate discretion will be exercised + to minimize unnecessary distribution of information about the + submitted vulnerability, and any experts brought in will act in + accordance of Security Officer policies. In the past, experts + have been brought in based on extensive experience with highly + complex components of the operating system, including FFS, the VM + system, and the network stack.

+ +

If a FreeBSD release process is underway, the FreeBSD Release + Engineer may also be notified that a vulnerability exists, and its + severity, so that informed decisions may be made regarding the + release cycle and any serious security bugs present in software + associated with an up-coming release. If requested, the Security + Officer will not share information regarding the nature of the + vulnerability with the Release Engineer, limiting information flow + to existence and severity.

+ +

The FreeBSD Security Officer has close working relationships with + a number of other organizations, including third-party vendors + that share code with FreeBSD (the OpenBSD, NetBSD and DragonFlyBSD + projects, Apple, and other vendors deriving software from FreeBSD, + as well as the Linux vendor security list), as well as + organizations that track vulnerabilities and security incidents, + such as CERT. Frequently vulnerabilities may extend beyond the + scope of the FreeBSD implementation, and (perhaps less frequently) + may have broad implications for the global networking community. + Under such circumstances, the Security Officer may wish to + disclose vulnerability information to these other organizations: + if you do not wish the Security Officer to do this, please + indicate so explicitly in any submissions.

+ +

Submitters should be careful to explicitly document any special + information handling requirements.

+ +

If the submitter of a vulnerability is interested in a + coordinated disclosure process with the submitter and/or other + vendors, this should be indicated explicitly in any submissions. + In the absence of explicit requests, the FreeBSD Security Officer + will select a disclosure schedule that reflects both a desire for + timely disclosure and appropriate testing of any solutions. + Submitters should be aware that if the vulnerability is being + actively discussed in public forums (such as bugtraq), and + actively exploited, the Security Officer may choose not to follow + a proposed disclosure timeline in order to provide maximum + protection for the user community.

+ +

Submissions may be protected using PGP. If desired, responses + will also be protected using PGP.

+ + + Modified: head/en_US.ISO8859-1/htdocs/security/security.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/security/security.xml Thu Apr 18 13:44:42 2013 (r41454) +++ head/en_US.ISO8859-1/htdocs/security/security.xml Thu Apr 18 13:58:37 2013 (r41455) @@ -16,228 +16,41 @@

Introduction

-

This web page is designed to assist both new and experienced - users in the area of FreeBSD security. FreeBSD takes security - very seriously and is constantly working on making the operating - system as secure as possible.

+

FreeBSD takes security very seriously and its developers are + constantly working on making the operating system as secure as + possible. This page will provide information about what to do in + the event of a security vulnerability affecting your system, and + how to report vulnerabilities.

Table of Contents

-

Other Security Links

+ +

Recent FreeBSD security vulnerabilities

- +

A full list of all security vulnerabilities can be found on this page.

-

How and where to report a FreeBSD security issue

- -

All FreeBSD security issues should be reported to the FreeBSD Security Team - or, if a higher level of confidentiality is required, PGP encrypted to the Security Officer Team - using the Security Officer PGP key. - All reports should at least contain:

- -
    -
  • A description of the vulnerability.
  • -
  • What versions of FreeBSD seem to be affected if possible.
  • -
  • Any plausible workaround.
  • -
  • Example code if possible.
  • -
+

How to update your system

-

After this information has been reported the Security Officer or - a Security Team delegate will get back with you.

- -

Spam filters

- -

Due to high volume of spam the main security contact mail - addresses are subject to spam filtering. If you cannot contact - the FreeBSD Security Officers or Security Team due to spam filters - (or suspect your mail has been filtered), please send mail to - security-officer-XXXX@FreeBSD.org with - XXXX replaced with 3432 instead of the normal - addresses. Note that this address will be changed periodically so - check back here for the latest address. Mails to this address - will go to the FreeBSD Security Officer Team.

- - -

The FreeBSD Security Officer Team and the FreeBSD Security Team

- -

In order that the FreeBSD Project may respond to vulnerability - reports in a timely manner, there are three members of the Security - Officer mail alias: the Security Officer, - Deputy Security Officer, and one Core Team member. - Therefore, messages sent to the <security-officer@FreeBSD.org> - mail alias are currently delivered to:

- - - - - - - - - - - - - - - - - - - - - - -
&a.des; <des@FreeBSD.org>Security Officer
&a.delphij; <delphij@FreeBSD.org>Deputy Security Officer
&a.simon; <simon@FreeBSD.org>Security Officer Emeritus
&a.cperciva; <cperciva@FreeBSD.org>Security Officer Emeritus
&a.rwatson; <rwatson@FreeBSD.org>Release Engineering liaison,
- TrustedBSD Project liaison, system security architecture expert
+

For most users, the easiest way to update your supported &os; + &rel.current; or &rel2.current; system is to use the following + commands:

-

The Security Officer is supported by the FreeBSD Security - Team <secteam@FreeBSD.org>, - a small group of committers vetted by the Security Officer.

- - -

Information handling policies

- -

As a general policy, the FreeBSD Security Officer favors full - disclosure of vulnerability information after a reasonable delay - to permit safe analysis and correction of a vulnerability, as well - as appropriate testing of the correction, and appropriate - coordination with other affected parties.

- -

The Security Officer will notify one or more of the - FreeBSD Cluster Admins of - vulnerabilities that put the FreeBSD Project's resources under - immediate danger.

- -

The Security Officer may bring additional FreeBSD developers or - outside developers into discussion of a submitted security - vulnerability if their expertise is required to fully understand - or correct the problem. Appropriate discretion will be exercised - to minimize unnecessary distribution of information about the - submitted vulnerability, and any experts brought in will act in - accordance of Security Officer policies. In the past, experts - have been brought in based on extensive experience with highly - complex components of the operating system, including FFS, the VM - system, and the network stack.

- -

If a FreeBSD release process is underway, the FreeBSD Release - Engineer may also be notified that a vulnerability exists, and its - severity, so that informed decisions may be made regarding the - release cycle and any serious security bugs present in software - associated with an up-coming release. If requested, the Security - Officer will not share information regarding the nature of the - vulnerability with the Release Engineer, limiting information flow - to existence and severity.

- -

The FreeBSD Security Officer has close working relationships with - a number of other organizations, including third-party vendors - that share code with FreeBSD (the OpenBSD, NetBSD and DragonFlyBSD - projects, Apple, and other vendors deriving software from FreeBSD, - as well as the Linux vendor security list), as well as - organizations that track vulnerabilities and security incidents, - such as CERT. Frequently vulnerabilities may extend beyond the - scope of the FreeBSD implementation, and (perhaps less frequently) - may have broad implications for the global networking community. - Under such circumstances, the Security Officer may wish to - disclose vulnerability information to these other organizations: - if you do not wish the Security Officer to do this, please - indicate so explicitly in any submissions.

- -

Submitters should be careful to explicitly document any special - information handling requirements.

- -

If the submitter of a vulnerability is interested in a - coordinated disclosure process with the submitter and/or other - vendors, this should be indicated explicitly in any submissions. - In the absence of explicit requests, the FreeBSD Security Officer - will select a disclosure schedule that reflects both a desire for - timely disclosure and appropriate testing of any solutions. - Submitters should be aware that if the vulnerability is being - actively discussed in public forums (such as bugtraq), and - actively exploited, the Security Officer may choose not to follow - a proposed disclosure timeline in order to provide maximum - protection for the user community.

+ # freebsd-update fetch
+ # freebsd-update install
-

Submissions may be protected using PGP. If desired, responses - will also be protected using PGP.

+

If that fails, follow the other instructions in the security + advisory you care about.

-

Supported FreeBSD Releases

- -

The FreeBSD Security Officer provides security advisories for - several branches of FreeBSD development. These are the - -STABLE Branches and the Security Branches. - (Advisories are not issued for the -CURRENT Branch.)

- -
    - -
  • The -STABLE branch tags have - names like RELENG_7. The corresponding builds have - names like FreeBSD 7.0-STABLE.

  • - -
  • Each FreeBSD Release has an associated Security Branch. - The Security Branch tags have names like RELENG_7_0. - The corresponding builds have names like FreeBSD - 7.0-RELEASE-p1.

  • -
- -

Issues affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML - document.

- -

Each branch is supported by the Security Officer for a limited - time only, and is designated as one of `Early adopter', - `Normal', or `Extended'. The designation is - used as a guideline for determining the lifetime of the branch as - follows.

- -
-
Early adopter
-
Releases which are published from the -CURRENT branch will be - supported by the Security Officer for a minimum of 6 months after - the release.
-
Normal
-
Releases which are published from a -STABLE branch will be - supported by the Security Officer for a minimum of 12 months after the - release, and for sufficient additional time (if needed) to ensure - that there is a newer release for at least 3 months before the - older Normal release expires. -
-
Extended
-
Selected releases (normally every second release plus the last - release from each -STABLE branch) will be supported by the - Security Officer for a minimum of 24 months after the release, - and for sufficient additional time (if needed) to ensure that - there is a newer Extended release for at least 3 months before the - older Extended release expires. -
-
- - +

Supported FreeBSD releases

The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL @@ -312,174 +125,52 @@ href="http://security.FreeBSD.org/patches/">patches subdirectories.

- -

Unsupported FreeBSD Releases

+

The FreeBSD Security Officer provides security advisories for + -STABLE Branches and the Security Branches. + (Advisories are not issued for the -CURRENT Branch.)

-

The following releases are no longer supported but are listed - here for reference purposes.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BranchReleaseTypeRelease DateEoL
RELENG_4n/an/an/aJanuary 31, 2007
RELENG_4_114.11-RELEASEExtendedJanuary 25, 2005January 31, 2007
RELENG_5n/an/an/aMay 31, 2008
RELENG_5_35.3-RELEASEExtendedNovember 6, 2004October 31, 2006
RELENG_5_45.4-RELEASENormalMay 9, 2005October 31, 2006
RELENG_5_55.5-RELEASEExtendedMay 25, 2006May 31, 2008
RELENG_6n/an/an/aNovember 30, 2010
RELENG_6_06.0-RELEASENormalNovember 4, 2005January 31, 2007
RELENG_6_16.1-RELEASEExtendedMay 9, 2006May 31, 2008
RELENG_6_26.2-RELEASENormalJanuary 15, 2007May 31, 2008
RELENG_6_36.3-RELEASEExtendedJanuary 18, 2008January 31, 2010
RELENG_6_46.4-RELEASEExtendedNovember 28, 2008November 30, 2010
RELENG_7n/an/an/aFebruary 28, 2013
RELENG_7_07.0-RELEASENormalFebruary 27, 2008April 30, 2009
RELENG_7_17.1-RELEASEExtendedJanuary 4, 2009February 28, 2011
RELENG_7_27.2-RELEASENormalMay 4, 2009June 30, 2010
RELENG_7_37.3-RELEASEExtendedMarch 23, 2010March 31, 2012
RELENG_7_47.4-RELEASEExtendedFebruary 24, 2011February 28, 2013
RELENG_8_08.0-RELEASENormalNovember 25, 2009November 30, 2010
RELENG_8_18.1-RELEASEExtendedJuly 23, 2010July 31, 2012
RELENG_8_28.2-RELEASENormalFebruary 24, 2011July 31, 2012
RELENG_9_09.0-RELEASENormalJanuary 10, 2012March 31, 2013
+
    +
  • The -STABLE branch tags have + names like RELENG_9. The corresponding builds have + names like FreeBSD 9.0-STABLE.

  • + +
  • Each FreeBSD Release has an associated Security Branch. + The Security Branch tags have names like RELENG_9_0. + The corresponding builds have names like FreeBSD + 9.0-RELEASE-p1.

  • +
+ +

Issues affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML + document.

+ +

Each branch is supported by the Security Officer for a limited + time only, and is designated as one of `Early adopter', + `Normal', or `Extended'. The designation is + used as a guideline for determining the lifetime of the branch as + follows.

+ +
+
Early adopter
+
Releases which are published from the -CURRENT branch will be + supported by the Security Officer for a minimum of 6 months after + the release.
+
Normal
+
Releases which are published from a -STABLE branch will be + supported by the Security Officer for a minimum of 12 months after the + release, and for sufficient additional time (if needed) to ensure + that there is a newer release for at least 3 months before the + older Normal release expires. +
+
Extended
+
Selected releases (normally every second release plus the last + release from each -STABLE branch) will be supported by the + Security Officer for a minimum of 24 months after the release, + and for sufficient additional time (if needed) to ensure that + there is a newer Extended release for at least 3 months before the + older Extended release expires. +
+
Added: head/en_US.ISO8859-1/htdocs/security/unsupported.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/en_US.ISO8859-1/htdocs/security/unsupported.xml Thu Apr 18 13:58:37 2013 (r41455) @@ -0,0 +1,185 @@ + + +]> + + + + + &title; + + $FreeBSD$ + + + + +

The following releases are no longer supported but are listed + here for reference purposes.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BranchReleaseTypeRelease DateEoL
RELENG_4n/an/an/aJanuary 31, 2007
RELENG_4_114.11-RELEASEExtendedJanuary 25, 2005January 31, 2007
RELENG_5n/an/an/aMay 31, 2008
RELENG_5_35.3-RELEASEExtendedNovember 6, 2004October 31, 2006
RELENG_5_45.4-RELEASENormalMay 9, 2005October 31, 2006
RELENG_5_55.5-RELEASEExtendedMay 25, 2006May 31, 2008
RELENG_6n/an/an/aNovember 30, 2010
RELENG_6_06.0-RELEASENormalNovember 4, 2005January 31, 2007
RELENG_6_16.1-RELEASEExtendedMay 9, 2006May 31, 2008
RELENG_6_26.2-RELEASENormalJanuary 15, 2007May 31, 2008
RELENG_6_36.3-RELEASEExtendedJanuary 18, 2008January 31, 2010
RELENG_6_46.4-RELEASEExtendedNovember 28, 2008November 30, 2010
RELENG_7n/an/an/aFebruary 28, 2013
RELENG_7_07.0-RELEASENormalFebruary 27, 2008April 30, 2009
RELENG_7_17.1-RELEASEExtendedJanuary 4, 2009February 28, 2011
RELENG_7_27.2-RELEASENormalMay 4, 2009June 30, 2010
RELENG_7_37.3-RELEASEExtendedMarch 23, 2010March 31, 2012
RELENG_7_47.4-RELEASEExtendedFebruary 24, 2011February 28, 2013
RELENG_8_08.0-RELEASENormalNovember 25, 2009November 30, 2010
RELENG_8_18.1-RELEASEExtendedJuly 23, 2010July 31, 2012
RELENG_8_28.2-RELEASENormalFebruary 24, 2011July 31, 2012
RELENG_9_09.0-RELEASENormalJanuary 10, 2012March 31, 2013
+ + + Modified: head/share/xml/navibar.ent ============================================================================== --- head/share/xml/navibar.ent Thu Apr 18 13:44:42 2013 (r41454) +++ head/share/xml/navibar.ent Thu Apr 18 13:58:37 2013 (r41455) @@ -170,6 +170,11 @@
  • Bug Reports