os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Start reorganising the security website pages:

Browse source 
- 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)
This commit is contained in:
Isabell Long 2013-04-18 13:58:37 +00:00
parent 96450b4bc4
commit b80a267da7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=41455
5 changed files with 428 additions and 375 deletions
en_US.ISO8859-1/htdocs/security
Makefilereporting.xmlsecurity.xmlunsupported.xml
share/xml
navibar.ent

2
en_US.ISO8859-1/htdocs/security/Makefile
View file

@ -15,6 +15,8 @@ DOCS= charter.xml
DOCS+= security.xml DOCS+= security.xml
DOCS+= advisories.xml DOCS+= advisories.xml
DOCS+= notices.xml DOCS+= notices.xml
DOCS+= reporting.xml
DOCS+= unsupported.xml
advisories.xml: advisories.html.inc advisories.xml: advisories.html.inc

170
en_US.ISO8859-1/htdocs/security/reporting.xml Normal file
View file

@ -0,0 +1,170 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/xml/xhtml10-freebsd.dtd" [
<!ENTITY title "FreeBSD Security Vulnerability Reporting Information">
]>
<!-- $FreeBSD$ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.support">
<h2>Table of contents</h2>
<ul>
<li><a href="#how">How and where to report a FreeBSD security issue</a></li>
<li><a href="#sec">Information about the FreeBSD Security Officer</a></li>
<li><a href="#pol">Information handling policies</a></li>
<li><a href="#sup">Supported FreeBSD Releases</a></li>
<li><a href="#unsup">Unsupported FreeBSD Releases</a></li>
</ul>
<a name="how"></a>
<h2>How and where to report a FreeBSD security issue</h2>
<p>All FreeBSD security issues should be reported to the <a
href="mailto:secteam@FreeBSD.org">FreeBSD Security Team</a>
or, if a higher level of confidentiality is required, PGP
encrypted to the <a
href="mailto:security-officer@FreeBSD.org">Security Officer
Team</a> using the <a href="so_public_key.asc">Security
Officer PGP key</a>. All reports should at least contain:</p>
<ul>
<li>A description of the vulnerability.</li>
<li>What versions of FreeBSD seem to be affected if possible.</li>
<li>Any plausible workaround.</li>
<li>Example code if possible.</li>
</ul>
<p>After this information has been reported the Security Officer
or a Security Team delegate will get back to you.</p>
<h3>Spam filters</h3>
<p>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
<tt>security-officer-<em>XXXX</em>@FreeBSD.org</tt> with
<em>XXXX</em> replaced with <tt>3432</tt> 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.</p>
<a name="sec"></a>
<h2>The FreeBSD Security Officer Team and the FreeBSD Security Team</h2>
<p>In order that the FreeBSD Project may respond to vulnerability
reports in a timely manner, emails sent to the <a
href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
mail alias are currently delivered to the following people:</p>
<table>
<tr valign="top">
<td>&a.des; <a
href="mailto:des@FreeBSD.org">&lt;des@FreeBSD.org&gt;</a></td>
<td>Security Officer</td>
</tr>
<tr valign="top">
<td>&a.delphij; <a
href="mailto:delphij@FreeBSD.org">&lt;delphij@FreeBSD.org&gt;</a></td>
<td>Deputy Security Officer</td>
</tr>
<tr valign="top">
<td>&a.simon; <a
href="mailto:simon@FreeBSD.org">&lt;simon@FreeBSD.org&gt;</a></td>
<td>Security Officer Emeritus</td>
</tr>
<tr valign="top">
<td>&a.cperciva; <a
href="mailto:cperciva@FreeBSD.org">&lt;cperciva@FreeBSD.org&gt;</a></td>
<td>Security Officer Emeritus</td>
</tr>
<tr valign="top">
<td>&a.rwatson; <a
href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
<td>Release Engineering liaison,<br/>
TrustedBSD Project liaison, system security architecture expert</td>
</tr>
</table>
<p>The Security Officer is supported by the <a
href="&base;/administration.html#t-secteam">FreeBSD Security
Team</a>, <a
href="mailto:secteam@FreeBSD.org">&lt;secteam@FreeBSD.org&gt;</a>,
a small group of committers vetted by the Security Officer.</p>
<a name="pol"></a>
<h2>Information handling policies</h2>
<p>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.</p>
<p>The Security Officer <em>will</em> notify one or more of the
FreeBSD Cluster Admins of
vulnerabilities that put the FreeBSD Project's resources under
immediate danger.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Submitters should be careful to explicitly document any special
information handling requirements.</p>
<p>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.</p>
<p>Submissions may be protected using PGP. If desired, responses
will also be protected using PGP.</p>
</body>
</html>

441
en_US.ISO8859-1/htdocs/security/security.xml
View file

@ -16,228 +16,41 @@
<h2>Introduction</h2> <h2>Introduction</h2>
<p>This web page is designed to assist both new and experienced <p>FreeBSD takes security very seriously and its developers are
users in the area of FreeBSD security. FreeBSD takes security constantly working on making the operating system as secure as
very seriously and is constantly working on making the operating possible. This page will provide information about what to do in
system as secure as possible.</p> the event of a security vulnerability affecting your system, and
how to report vulnerabilities.</p>
<h2>Table of Contents</h2> <h2>Table of Contents</h2>
<ul> <ul>
<li><a href="#how">How and where to report a FreeBSD security issue</a></li> <li><a href="#recent">Recent FreeBSD security vulnerabilities</a></li>
<li><a href="#sec">Information about the FreeBSD Security Officer</a></li> <li><a href="#how">How to update your system</a></li>
<li><a href="#pol">Information handling policies</a></li> <li><a href="reporting.html">Reporting FreeBSD security incidents</a></li>
<li><a href="#sup">Supported FreeBSD Releases</a></li>
<li><a href="#unsup">Unsupported FreeBSD Releases</a></li>
</ul> </ul>
<h2>Other Security Links</h2> <a name="recent"></a>
<h2>Recent FreeBSD security vulnerabilities</h2>
<ul> <p>A full list of all security vulnerabilities can be found <a
<li><a href="charter.html">Charter for the Security Officer and Team</a></li> href="advisories.html">on this page</a>.</p>
<li><a href="advisories.html">List of FreeBSD Security Advisories</a></li>
<li><a href="notices.html">List of FreeBSD Errata Notices</a></li>
<li><a href="&base;/doc/en_US.ISO8859-1/books/handbook/security-advisories.html">
Reading FreeBSD Security Advisories</a></li>
</ul>
<a name="how"></a> <a name="how"></a>
<h2>How and where to report a FreeBSD security issue</h2> <h2>How to update your system</h2>
<p>All FreeBSD security issues should be reported to the <a <p>For most users, the easiest way to update your supported &os;
href="mailto:secteam@FreeBSD.org">FreeBSD Security Team</a> &rel.current; or &rel2.current; system is to use the following
or, if a higher level of confidentiality is required, PGP encrypted to the <a commands:</p>
href="mailto:security-officer@FreeBSD.org">Security Officer Team</a>
using the <a href="so_public_key.asc">Security Officer PGP key</a>.
All reports should at least contain:</p>
<ul> <tt># freebsd-update fetch<br />
<li>A description of the vulnerability.</li> # freebsd-update install</tt>
<li>What versions of FreeBSD seem to be affected if possible.</li>
<li>Any plausible workaround.</li>
<li>Example code if possible.</li>
</ul>
<p>After this information has been reported the Security Officer or <p>If that fails, follow the other instructions in the security
a Security Team delegate will get back with you.</p> advisory you care about.</p>
<h3>Spam filters</h3>
<p>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
<tt>security-officer-<em>XXXX</em>@FreeBSD.org</tt> with
<em>XXXX</em> replaced with <tt>3432</tt> 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.</p>
<a name="sec"></a>
<h2>The FreeBSD Security Officer Team and the FreeBSD Security Team</h2>
<p>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 <a
href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
mail alias are currently delivered to:</p>
<table>
<tr valign="top">
<td>&a.des; <a
href="mailto:des@FreeBSD.org">&lt;des@FreeBSD.org&gt;</a></td>
<td>Security Officer</td>
</tr>
<tr valign="top">
<td>&a.delphij; <a
href="mailto:delphij@FreeBSD.org">&lt;delphij@FreeBSD.org&gt;</a></td>
<td>Deputy Security Officer</td>
</tr>
<tr valign="top">
<td>&a.simon; <a
href="mailto:simon@FreeBSD.org">&lt;simon@FreeBSD.org&gt;</a></td>
<td>Security Officer Emeritus</td>
</tr>
<tr valign="top">
<td>&a.cperciva; <a
href="mailto:cperciva@FreeBSD.org">&lt;cperciva@FreeBSD.org&gt;</a></td>
<td>Security Officer Emeritus</td>
</tr>
<tr valign="top">
<td>&a.rwatson; <a
href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
<td>Release Engineering liaison,<br/>
TrustedBSD Project liaison, system security architecture expert</td>
</tr>
</table>
<p>The Security Officer is supported by the <a
href="&base;/administration.html#t-secteam" >FreeBSD Security
Team</a> <a
href="mailto:secteam@FreeBSD.org">&lt;secteam@FreeBSD.org&gt;</a>,
a small group of committers vetted by the Security Officer.</p>
<a name="pol"></a>
<h2>Information handling policies</h2>
<p>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.</p>
<p>The Security Officer <em>will</em> notify one or more of the
FreeBSD Cluster Admins of
vulnerabilities that put the FreeBSD Project's resources under
immediate danger.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Submitters should be careful to explicitly document any special
information handling requirements.</p>
<p>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.</p>
<p>Submissions may be protected using PGP. If desired, responses
will also be protected using PGP.</p>
<a name="sup"></a> <a name="sup"></a>
<h2>Supported FreeBSD Releases</h2> <h2>Supported FreeBSD releases</h2>
<p>The FreeBSD Security Officer provides security advisories for
several branches of FreeBSD development. These are the
<em>-STABLE Branches</em> and the <em>Security Branches</em>.
(Advisories are not issued for the <em>-CURRENT Branch</em>.)</p>
<ul>
<li><p>The -STABLE branch tags have
names like <tt>RELENG_7</tt>. The corresponding builds have
names like <tt>FreeBSD 7.0-STABLE</tt>.</p></li>
<li><p>Each FreeBSD Release has an associated Security Branch.
The Security Branch tags have names like <tt>RELENG_7_0</tt>.
The corresponding builds have names like <tt>FreeBSD
7.0-RELEASE-p1</tt>.</p></li>
</ul>
<p>Issues affecting the FreeBSD Ports Collection are covered in <a
href="http://vuxml.FreeBSD.org/">the FreeBSD VuXML
document</a>.</p>
<p>Each branch is supported by the Security Officer for a limited
time only, and is designated as one of `<em>Early adopter</em>',
`<em>Normal</em>', or `<em>Extended</em>'. The designation is
used as a guideline for determining the lifetime of the branch as
follows.</p>
<dl>
<dt>Early adopter</dt>
<dd>Releases which are published from the -CURRENT branch will be
supported by the Security Officer for a minimum of 6 months after
the release.</dd>
<dt>Normal</dt>
<dd>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.
</dd>
<dt>Extended</dt>
<dd>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.
</dd>
</dl>
<a name="supported-branches"></a>
<p>The current designation and estimated lifetimes of the currently <p>The current designation and estimated lifetimes of the currently
supported branches are given below. The <em>Estimated EoL supported branches are given below. The <em>Estimated EoL
@ -312,174 +125,52 @@
href="http://security.FreeBSD.org/patches/">patches</a> href="http://security.FreeBSD.org/patches/">patches</a>
subdirectories.</p> subdirectories.</p>
<a name="unsup"></a> <p>The FreeBSD Security Officer provides security advisories for
<h2>Unsupported FreeBSD Releases</h2> <em>-STABLE Branches</em> and the <em>Security Branches</em>.
(Advisories are not issued for the <em>-CURRENT Branch</em>.)</p>
<p>The following releases are no longer supported but are listed <ul>
here for reference purposes.</p> <li><p>The -STABLE branch tags have
<table class="tblbasic"> names like <tt>RELENG_9</tt>. The corresponding builds have
<tr> names like <tt>FreeBSD 9.0-STABLE</tt>.</p></li>
<th>Branch</th>
<th>Release</th> <li><p>Each FreeBSD Release has an associated Security Branch.
<th>Type</th> The Security Branch tags have names like <tt>RELENG_9_0</tt>.
<th>Release Date</th> The corresponding builds have names like <tt>FreeBSD
<th>EoL</th> 9.0-RELEASE-p1</tt>.</p></li>
</tr> </ul>
<tr>
<td>RELENG_4</td> <p>Issues affecting the FreeBSD Ports Collection are covered in <a
<td>n/a</td> href="http://vuxml.FreeBSD.org/">the FreeBSD VuXML
<td>n/a</td> document</a>.</p>
<td>n/a</td>
<td>January 31, 2007</td> <p>Each branch is supported by the Security Officer for a limited
</tr> time only, and is designated as one of `<em>Early adopter</em>',
<tr> `<em>Normal</em>', or `<em>Extended</em>'. The designation is
<td>RELENG_4_11</td> used as a guideline for determining the lifetime of the branch as
<td>4.11-RELEASE</td> follows.</p>
<td>Extended</td>
<td>January 25, 2005</td> <dl>
<td>January 31, 2007</td> <dt>Early adopter</dt>
</tr> <dd>Releases which are published from the -CURRENT branch will be
<tr> supported by the Security Officer for a minimum of 6 months after
<td>RELENG_5</td> the release.</dd>
<td>n/a</td> <dt>Normal</dt>
<td>n/a</td> <dd>Releases which are published from a -STABLE branch will be
<td>n/a</td> supported by the Security Officer for a minimum of 12 months after the
<td>May 31, 2008</td> release, and for sufficient additional time (if needed) to ensure
</tr> that there is a newer release for at least 3 months before the
<tr> older Normal release expires.
<td>RELENG_5_3</td> </dd>
<td>5.3-RELEASE</td> <dt>Extended</dt>
<td>Extended</td> <dd>Selected releases (normally every second release plus the last
<td>November 6, 2004</td> release from each -STABLE branch) will be supported by the
<td>October 31, 2006</td> Security Officer for a minimum of 24 months after the release,
</tr> and for sufficient additional time (if needed) to ensure that
<tr> there is a newer Extended release for at least 3 months before the
<td>RELENG_5_4</td> older Extended release expires.
<td>5.4-RELEASE</td> </dd>
<td>Normal</td> </dl>
<td>May 9, 2005</td>
<td>October 31, 2006</td>
</tr>
<tr>
<td>RELENG_5_5</td>
<td>5.5-RELEASE</td>
<td>Extended</td>
<td>May 25, 2006</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_6_0</td>
<td>6.0-RELEASE</td>
<td>Normal</td>
<td>November 4, 2005</td>
<td>January 31, 2007</td>
</tr>
<tr>
<td>RELENG_6_1</td>
<td>6.1-RELEASE</td>
<td>Extended</td>
<td>May 9, 2006</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6_2</td>
<td>6.2-RELEASE</td>
<td>Normal</td>
<td>January 15, 2007</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6_3</td>
<td>6.3-RELEASE</td>
<td>Extended</td>
<td>January 18, 2008</td>
<td>January 31, 2010</td>
</tr>
<tr>
<td>RELENG_6_4</td>
<td>6.4-RELEASE</td>
<td>Extended</td>
<td>November 28, 2008</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_7</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>February 28, 2013</td>
</tr>
<tr>
<td>RELENG_7_0</td>
<td>7.0-RELEASE</td>
<td>Normal</td>
<td>February 27, 2008</td>
<td>April 30, 2009</td>
</tr>
<tr>
<td>RELENG_7_1</td>
<td>7.1-RELEASE</td>
<td>Extended</td>
<td>January 4, 2009</td>
<td>February 28, 2011</td>
</tr>
<tr>
<td>RELENG_7_2</td>
<td>7.2-RELEASE</td>
<td>Normal</td>
<td>May 4, 2009</td>
<td>June 30, 2010</td>
</tr>
<tr>
<td>RELENG_7_3</td>
<td>7.3-RELEASE</td>
<td>Extended</td>
<td>March 23, 2010</td>
<td>March 31, 2012</td>
</tr>
<tr>
<td>RELENG_7_4</td>
<td>7.4-RELEASE</td>
<td>Extended</td>
<td>February 24, 2011</td>
<td>February 28, 2013</td>
</tr>
<tr>
<td>RELENG_8_0</td>
<td>8.0-RELEASE</td>
<td>Normal</td>
<td>November 25, 2009</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_8_1</td>
<td>8.1-RELEASE</td>
<td>Extended</td>
<td>July 23, 2010</td>
<td>July 31, 2012</td>
</tr>
<tr>
<td>RELENG_8_2</td>
<td>8.2-RELEASE</td>
<td>Normal</td>
<td>February 24, 2011</td>
<td>July 31, 2012</td>
</tr>
<tr>
<td>RELENG_9_0</td>
<td>9.0-RELEASE</td>
<td>Normal</td>
<td>January 10, 2012</td>
<td>March 31, 2013</td>
</tr>
</table>
</body> </body>
</html> </html>

185
en_US.ISO8859-1/htdocs/security/unsupported.xml Normal file
View file

@ -0,0 +1,185 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/xml/xhtml10-freebsd.dtd" [
<!ENTITY title "Unsupported FreeBSD Releases">
]>
<!-- $FreeBSD$ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.support">
<p>The following releases are no longer supported but are listed
here for reference purposes.</p>
<table class="tblbasic">
<tr>
<th>Branch</th>
<th>Release</th>
<th>Type</th>
<th>Release Date</th>
<th>EoL</th>
</tr>
<tr>
<td>RELENG_4</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>January 31, 2007</td>
</tr>
<tr>
<td>RELENG_4_11</td>
<td>4.11-RELEASE</td>
<td>Extended</td>
<td>January 25, 2005</td>
<td>January 31, 2007</td>
</tr>
<tr>
<td>RELENG_5</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_5_3</td>
<td>5.3-RELEASE</td>
<td>Extended</td>
<td>November 6, 2004</td>
<td>October 31, 2006</td>
</tr>
<tr>
<td>RELENG_5_4</td>
<td>5.4-RELEASE</td>
<td>Normal</td>
<td>May 9, 2005</td>
<td>October 31, 2006</td>
</tr>
<tr>
<td>RELENG_5_5</td>
<td>5.5-RELEASE</td>
<td>Extended</td>
<td>May 25, 2006</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_6_0</td>
<td>6.0-RELEASE</td>
<td>Normal</td>
<td>November 4, 2005</td>
<td>January 31, 2007</td>
</tr>
<tr>
<td>RELENG_6_1</td>
<td>6.1-RELEASE</td>
<td>Extended</td>
<td>May 9, 2006</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6_2</td>
<td>6.2-RELEASE</td>
<td>Normal</td>
<td>January 15, 2007</td>
<td>May 31, 2008</td>
</tr>
<tr>
<td>RELENG_6_3</td>
<td>6.3-RELEASE</td>
<td>Extended</td>
<td>January 18, 2008</td>
<td>January 31, 2010</td>
</tr>
<tr>
<td>RELENG_6_4</td>
<td>6.4-RELEASE</td>
<td>Extended</td>
<td>November 28, 2008</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_7</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>February 28, 2013</td>
</tr>
<tr>
<td>RELENG_7_0</td>
<td>7.0-RELEASE</td>
<td>Normal</td>
<td>February 27, 2008</td>
<td>April 30, 2009</td>
</tr>
<tr>
<td>RELENG_7_1</td>
<td>7.1-RELEASE</td>
<td>Extended</td>
<td>January 4, 2009</td>
<td>February 28, 2011</td>
</tr>
<tr>
<td>RELENG_7_2</td>
<td>7.2-RELEASE</td>
<td>Normal</td>
<td>May 4, 2009</td>
<td>June 30, 2010</td>
</tr>
<tr>
<td>RELENG_7_3</td>
<td>7.3-RELEASE</td>
<td>Extended</td>
<td>March 23, 2010</td>
<td>March 31, 2012</td>
</tr>
<tr>
<td>RELENG_7_4</td>
<td>7.4-RELEASE</td>
<td>Extended</td>
<td>February 24, 2011</td>
<td>February 28, 2013</td>
</tr>
<tr>
<td>RELENG_8_0</td>
<td>8.0-RELEASE</td>
<td>Normal</td>
<td>November 25, 2009</td>
<td>November 30, 2010</td>
</tr>
<tr>
<td>RELENG_8_1</td>
<td>8.1-RELEASE</td>
<td>Extended</td>
<td>July 23, 2010</td>
<td>July 31, 2012</td>
</tr>
<tr>
<td>RELENG_8_2</td>
<td>8.2-RELEASE</td>
<td>Normal</td>
<td>February 24, 2011</td>
<td>July 31, 2012</td>
</tr>
<tr>
<td>RELENG_9_0</td>
<td>9.0-RELEASE</td>
<td>Normal</td>
<td>January 10, 2012</td>
<td>March 31, 2013</td>
</tr>
</table>
</body>
</html>

5
share/xml/navibar.ent
View file

@ -170,6 +170,11 @@
<ul> <ul>
<li><a href="&base;/security/advisories.html">Advisories</a></li> <li><a href="&base;/security/advisories.html">Advisories</a></li>
<li><a href="&base;/security/notices.html">Errata Notices</a></li> <li><a href="&base;/security/notices.html">Errata Notices</a></li>
<li><a href="&base;/security/supported.html">Supported Releases</a></li>
<li><a href="&base;/security/unsupported.html">Unsupported Releases</a></li>
<li><a href="&base;/doc/en_US.ISO8859-1/books/handbook/security-advisories.html">
How to read FreeBSD Security Advisories</a></li>
<li><a href="charter.html">Charter for the Security Officer and Team</a></li>
</ul></li> </ul></li>
<li><a href="&base;/support/bugreports.html">Bug Reports</a> <li><a href="&base;/support/bugreports.html">Bug Reports</a>
<ul> <ul>