<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.199 $">
+ <!entity cvs-rev "$Revision: 1.200 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
Extra care should be taken when uploading to <em>stable</em>. Basically, a
package should only be uploaded to stable if one of the following happens:
<list>
- <item>a security problem (e.g. a Debian security advisory)
<item>a truly critical functionality problem
<item>the package becomes uninstallable
<item>a released architecture lacks the package
</list>
+<p>
+In the past, uploads to <em>stable</em> were used to address security
+problems as well. However, this practice is deprecated, as uploads
+used for Debian security advisories are automatically copied to the
+appropriate <file>proposed-updates</file> archive when the advisory is
+released. See <ref id="bug-security"> for detailed information on
+handling security problems.
<p>
It is discouraged to change anything else in the package that isn't
-important, because even trivial fixes can cause bugs later on. Uploading
-new upstream versions to fix security problems is deprecated; applying the
-specific patch from the new upstream version to the old one ("back-porting"
-the patch) is the right thing to do in most cases.
+important, because even trivial fixes can cause bugs later on.
<p>
Packages uploaded to <em>stable</em> need to be compiled on systems running
<em>stable</em>, so that their dependencies are limited to the libraries
<!-- information about the security database goes here once it's ready -->
<!-- (mdz) -->
- <sect2 id="bug-security-you">What to do when you learn of a
- security problem
- <p>
+<p>
When you become aware of a security-related bug in a Debian package,
whether or not you are the maintainer, collect pertinent information
-about the problem, and promptly contact the security team at
-&email-security-team;.
-Useful information includes, for example:
+about the problem, and promptly contact the security team at
+&email-security-team; as soon as possible. Useful information
+includes, for example:
<list compact>
<item>What versions of the package are known to be affected by the
especially helpful)
<item>Any fixed packages that you have prepared yourself (send only
- the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+ the <tt>.diff.gz</tt> and <tt>.dsc</tt> files and read <ref
+ id="bug-security-building"> first)
+
+ <item>Any assistance you can provide to help with testing (exploits,
+ regression testing, etc.)
<item>Any information needed for the advisory (see <ref
id="bug-security-advisories">)
<sect2 id="bug-security-confidentiality">Confidentiality
<p>
Unlike most other activities within Debian, information about security
-issues must sometimes be kept private for a time. Whether this is the
+issues must sometimes be kept private for a time.
+This allows software distributors to coordinate their disclosure in
+order to minimize their users' exposure. Whether this is the
case depends on the nature of the problem and corresponding fix, and
whether it is already a matter of public knowledge.
+
<p>
There are a few ways a developer can learn of a security problem:
possible options for dealing with the problem:
<list>
- <item>if it is a trivial problem (like insecure temporary files)
- there is no need to keep the problem a secret and a fix should be
- made and released.
+ <item>If the security exposure is minor, there is sometimes no need
+ to keep the problem a secret and a fix should be made and released.
- <item>if the problem is severe (remotely exploitable, possibility to
- gain root privileges) it is preferable to share the information with
+ <item>If the problem is severe, it is preferable to share the
+ information with
other vendors and coordinate a release. The security team keeps
contacts with the various organizations and individuals and can take
care of that.
</list>
<p>
- In all cases if the person who reports the problem asks to not
- disclose the information that should be respected, with the obvious
- exception of informing the security team (make sure you tell the
- security team that the information can not be disclosed).
+ In all cases if the person who reports the problem asks that it not
+ be disclosed, such requests should be honored, with the obvious
+ exception of informing the security team in order that a fix may be
+ produced for a stable release of Debian. When sending confidential
+ information to the security team, be sure to mention this fact.
<p>
-Please note that if secrecy is needed you can also not upload a fix to
-unstable (or anywhere else), since the changelog and diff information
-for unstable is public.
+Please note that if secrecy is needed you may not upload a fix to
+unstable (or anywhere else, such as a public CVS repository). It is
+not sufficient to obfuscate the details of the change, as the code
+itself is public, and can (and will) be examined by the general public.
<p>
There are two reasons for releasing information even though secrecy is
<sect2 id="bug-security-advisories">Security Advisories
<p>
Security advisories are only issued for the current, released stable
-distribution, not for testing or unstable. When released, advisories
+distribution, and <em>not</em> for testing or unstable. When released,
+advisories
are sent to the &email-debian-security-announce;
+
mailing list and posted on <url
id="&url-debian-security-advisories;" name="the security web page">.
Security advisories are written and posted by the security
-team. However they certainly do not mind if a maintainer can supply
-some of the information for them, or write part of the
-text. Information that should be in an advisory includes:
+team. However they certainly do not mind if a
+maintainer can supply some of the information for them, or write part
+of the text. Information that should be in an advisory includes:
<list compact>
<item>A description of the problem and its scope, including:
<list>
<item>The type of problem (privilege escalation, denial of
service, etc.)
+ <item>What privileges may be gained, and by whom (if any)
<item>How it can be exploited
<item>Whether it is remotely or locally exploitable
<item>How the problem was fixed
</list>
+
+ This information allows users to assess the threat to their systems.
+
<item>Version numbers of affected packages
<item>Version numbers of fixed packages
<item>Information on where to obtain the updated packages
+ (usually from the Debian security archive)
<item>References to upstream advisories, <url
id="http://cve.mitre.org" name="CVE"> identifiers, and any other
information useful in cross-referencing the vulnerability
<heading>Preparing packages to address security issues</heading>
<p>
One way that you can assist the security team in their duties is to
-provide fixed packages suitable for a security advisory for the stable
+provide them with fixed packages suitable for a security advisory for
+the stable
Debian release.
<p>
When an update is made to the stable release, care must be taken to
avoid changing system behavior or introducing new bugs. In order to
do this, make as few changes as possible to fix the bug. Users and
administrators rely on the exact behavior of a release once it is
- made, so any change that is made might break someone's system.
- This is especially true of libraries: make sure you never change the
- API or ABI, no matter how small the change.
+ made, so any change that is made might break someone's system. This
+ is especially true of libraries: make sure you never change the API or
+ ABI, no matter how small the change.
<p>
This means that moving to a new upstream version is not a good
solution. Instead, the relevant changes should be back-ported to the
In some cases, it is not possible to back-port a security fix, for
example when large amounts of source code need to be modified or
rewritten. If this happens, it may be necessary to move to a new
-upstream version. However, you must always coordinate that with the
-security team beforehand.
+upstream version. However, this is only done in extreme situations,
+and you must always coordinate that with the security team beforehand.
<p>
Related to this is another important guideline: always test your
changes. If you have an exploit available, try it and see if it
stable release, this is <tt>oldstable-security</tt>. Do not target
<var>distribution</var>-proposed-updates!
+ <item>Make descriptive, meaningful changelog entries. Others will
+ rely on them to determine whether a particular bug was fixed.
+ Whenever possible, include an external reference, preferably a CVE
+ identifier, so that it can be cross-referenced.
+
<item>Make sure the version number is proper. It must be greater
than the current package, but less than package versions in later
distributions. If in doubt, test it with <tt>dpkg
normal archive, otherwise it is not possible to move the security
fix into the main archives later.
- <item>Be sure, when compiling a package, to compile on a clean
+ <item>Be sure to build the package on a clean
system which only has packages installed from the distribution you
are building for. If you do not have such a system yourself, you
can use a debian.org machine (see <ref id="server-machines">)
<sect2 id="bug-security-upload">Uploading the fixed package
<p>
-<em>DO NOT</em> upload a package to the security upload queue without
+<em>DO NOT</em> upload a package to the security upload queue
+(oldstable-security, stable-security, etc.) without
prior authorization from the security team. If the package does not
exactly meet the team's requirements, it will cause many problems and
delays in dealing with the unwanted upload.
<var>distribution</var>-proposed-updates on ftp-master or in the non-US
archive.
-
<sect id="archive-manip">
<heading>Moving, removing, renaming, adopting, and orphaning
packages</heading>
~ianmdlvl / developers-reference.git / commitdiff