1d9bea10ed
The primary purposes are to clean up duplicated author definitions in
both share/xml/authors.ent and share/xml/developers.ent, and as a added
bonus simplify writing up author names/email addresses in web pages.
Apart from merging developers.ent into authors.ent, removing the former,
and updating the Committers Guide there should be little user-visible changes:
- a.portmgr renamed to a.portmgr.members
- a.doceng renamed to a.doceng.members
- team.re renamed to a.re.members.email and moved from
share/xml/freebsd.ent to share/xml/authors.ent
- a.core updated and moved from share/xml/mailing-lists.ent to
share/xml/teams.ent
- share/pgpkeys/{addkey.sh|README} updated
Translations are untouched except for build fixes.
Approved by: doceng (gjb)
Approved by: gjb (mentor)
165 lines
7 KiB
XML
165 lines
7 KiB
XML
<?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="security.html#sup">Supported FreeBSD Releases</a></li>
|
|
<li><a href="unsupported.html">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"><security-officer@FreeBSD.org></a>
|
|
mail alias are currently delivered to the following people:</p>
|
|
|
|
<table>
|
|
<tr valign="top">
|
|
<td>&a.des.email;</td>
|
|
<td>Security Officer</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.delphij.email;</td>
|
|
<td>Deputy Security Officer</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.simon.email;</td>
|
|
<td>Security Officer Emeritus</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.cperciva.email;</td>
|
|
<td>Security Officer Emeritus</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td>&a.rwatson.email;</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"><secteam@FreeBSD.org></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>
|