diff --git a/en/releng/index.sgml b/en/releng/index.sgml index d2d8f466d2..17f9b32858 100644 --- a/en/releng/index.sgml +++ b/en/releng/index.sgml @@ -1,438 +1,438 @@ - + %developers; re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> freebsd-doc@FreeBSD.org'> doceng@FreeBSD.org'> freebsd-www@FreeBSD.org'> ]> &header;

This page contains documentation about the FreeBSD release engineering process.

Upcoming Release Schedule

NOTE: Release dates are approximate and may be subject to schedule slippage.

Date Event Information
May 2009 FreeBSD 7.2 released on schedule
August 2009 FreeBSD 8.0  

Code-Freeze Status

The following table lists the code freeze status for the major branches of the src/ subtree of the FreeBSD CVS repository. Commits to any branch listed as "frozen" must first be reviewed and approved by the relevant contact party. The status of other subtrees such as ports/, doc/, and www/ is also provided below.

- +
Branch Status Contact Notes
HEAD Open committers Active development branch for 8-CURRENT.
RELENG_7 Open &contact.re; Development branch for 7-STABLE.
RELENG_7_2 Frozen &contact.re; FreeBSD 7.2 supported errata fix branch.
RELENG_7_1 Frozen &contact.so; FreeBSD 7.1 supported errata fix branch.
RELENG_7_0 Frozen &contact.so;FreeBSD 7.0 supported errata fix branch.FreeBSD 7.0 errata fix branch (not officially supported).
RELENG_6 Open committers Development branch for 6-STABLE.
RELENG_6_4 Frozen &contact.so; FreeBSD 6.4 supported errata fix branch.
RELENG_6_3 Frozen &contact.so; FreeBSD 6.3 supported errata fix branch.
RELENG_6_2 Frozen &contact.so; FreeBSD 6.2 errata fix branch (not officially supported).
RELENG_6_1 Frozen &contact.so; FreeBSD 6.1 errata fix branch (not officially supported).
RELENG_6_0 Frozen &contact.so; FreeBSD 6.0 errata fix branch (not officially supported).
RELENG_5 Open committers Maintenance branch for 5-STABLE (not officially supported).
RELENG_5_5 Frozen &contact.so; FreeBSD 5.5 errata fix branch (not officially supported).
RELENG_5_4 Frozen &contact.so; FreeBSD 5.4 errata fix branch (not officially supported).
RELENG_5_3 Frozen &contact.so; FreeBSD 5.3 errata fix branch (not officially supported).
RELENG_5_2 Frozen &contact.so; FreeBSD 5.2 / 5.2.1 security fix branch (not officially supported).
RELENG_5_1 Frozen &contact.so; FreeBSD 5.1 security fix branch (not officially supported).
RELENG_5_0 Frozen &contact.so; FreeBSD 5.0 security fix branch (not officially supported).
RELENG_4 Open committers Maintenance branch for 4-STABLE (not officially supported).
RELENG_4_11 Frozen &contact.so; FreeBSD 4.11 errata fix branch (not officially supported).
RELENG_4_10 Frozen &contact.so; FreeBSD 4.10 security fix branch (not officially supported).
RELENG_4_9 Frozen &contact.so; FreeBSD 4.9 security fix branch (not officially supported).
RELENG_4_8 Frozen &contact.so; FreeBSD 4.8 security fix branch (not officially supported).
RELENG_4_7 Frozen &contact.so; FreeBSD 4.7 security fix branch (not officially supported).
RELENG_4_6 Frozen &contact.so; FreeBSD 4.6 security fix branch (not officially supported).
RELENG_4_5 Frozen &contact.so; FreeBSD 4.5 security fix branch (not officially supported).
RELENG_4_4 Frozen &contact.so; FreeBSD 4.4 security fix branch (not officially supported).
RELENG_4_3 Frozen &contact.so; FreeBSD 4.3 security fix branch (not officially supported).
RELENG_3 Open committers Maintenance branch for 3-STABLE (not officially supported).
RELENG_2_2 Open committers Maintenance branch for 2.2-STABLE (not officially supported).
Subtree Status Contact Notes
ports/ Open &contact.portmgr; FreeBSD Ports Collection.
doc/ Open &contact.doc; SGML/XML based documentation set.
www/ Open &contact.www; FreeBSD Web site sources.

Release Engineering Documentation

Release Engineering Team

The primary release engineering team is responsible for approving MFC requests during code freezes, setting release schedules, and all of the other responsibilities laid out in our charter.

Primary RE Team (re@FreeBSD.org) : &a.re.members; form the primary release engineering decision-making group.

The platform-specific release engineering teams are responsible for building and packaging FreeBSD releases on the given platforms.

Alpha Platform REs (re-alpha@FreeBSD.org) : &a.re-alpha;

AMD64 Platform REs (re-amd64@FreeBSD.org) : &a.re-amd64;

ia64 Platform REs (re-ia64@FreeBSD.org) : &a.re-ia64;

i386 Platform REs (re-x86@FreeBSD.org) : &a.re-i386;

pc98 Platform REs (re-pc98@FreeBSD.org) : &a.re-pc98;

PowerPC Platform REs (re-ppc@FreeBSD.org) : &a.re-powerpc;

sparc64 Platform REs (re-sparc64@FreeBSD.org) : &a.re-sparc64;

The third party packages in the Ports Collection are managed by the portmgr@ team. Among many other responsibilities, the port managers keep the ports cluster running smoothly to produce binary packages.

Package Builders (&contact.portmgr;) : &a.portmgr;

Frequently Asked Questions

Where can I find the release directory or ISO images for older FreeBSD releases?

The FreeBSD Project does not maintain a centralized historical archive of old release ISO images, but there are still many options. First, a large collection of the old releases (many complete with the package sets) is at ftp://ftp-archive.FreeBSD.org/pub/FreeBSD-Archive/old-releases/. Second, try looking on http://mirrorlist.FreeBSD.org. If you are unable to find an FTP mirror that still contains the release you are looking for, then you can email CD-ROM vendors to see if they have any old releases available. In September 2003, we know of a case where FreeBSD 1.1 was used in a court of law to invalidate a bogus software patent. Clearly, older releases can be very important in some situations.

&footer; diff --git a/en/security/security.sgml b/en/security/security.sgml index 2791a448df..3a17da8ff9 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,309 +1,316 @@ - + %developers; ]> - + &header;

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.

Table of Contents

Other Security Links

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:

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, 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.cperciva; <cperciva@FreeBSD.org> Security Officer
&a.simon; <simon@FreeBSD.org> Deputy Security Officer
&a.rwatson; <rwatson@FreeBSD.org> FreeBSD Core Team liaison, 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.

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.)

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.

The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed.

+ + + + + + +
Branch Release Type Release Date Estimated EoL
RELENG_6 n/a n/a n/a November 30, 2010
RELENG_6_3 6.3-RELEASE Extended January 18, 2008 January 31, 2010
RELENG_6_4 6.4-RELEASE Extended November 28, 2008 November 30, 2010
RELENG_7 n/a n/a n/a last release + 2 years
RELENG_7_1 7.1-RELEASE Extended January 4, 2009 January 31, 2011
RELENG_7_27.2-RELEASENormalMay 4, 2009May 31, 2010

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Advisories are sent to the following FreeBSD mailing lists:

The list of released advisories can be found on the FreeBSD Security Advisories page.

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at the http://security.FreeBSD.org/ web server in the advisories and patches subdirectories.

&footer;