<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.136 $">
+ <!entity cvs-rev "$Revision: 1.137 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
<list compact>
<item>What versions of the package are known to be affected by the
- bug.
-
- <item>The nature of the exposure (root compromise, user compromise,
- remote/local attack)
+ bug. Check each version that is present in a supported Debian
+ release, as well as testing and unstable.
<item>The nature of the fix, if any is available (patches are
especially helpful)
+
+ <item>Any fixed packages that you have prepared yourself (send only
+ the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+
+ <item>Any information needed for the advisory (see <ref
+ id="bug-security-advisories">)
+
</list>
<sect2 id="bug-security-confidentiality">Confidentiality
<item>Version numbers of affected packages
<item>Version numbers of fixed packages
<item>Information on where to obtain the updated packages
+ <item>References to upstream advisories, <url
+ id="http://cve.mitre.org" name="CVE"> identifiers, and any other
+ information useful in cross-referencing the vulnerability
</list>
<sect2 id="bug-security-building">
indeed succeeds on the unpatched package and fails on the fixed
package. Test other, normal actions as well, as sometimes a security
fix can break seemingly unrelated features in subtle ways.
+<p>
+Review and test your changes as much as possible. Check the
+differences from the previous version repeatedly
+(<prgn>interdiff</prgn> and <prgn>debdiff</prgn> are useful tools for
+this).
When packaging the fix, keep the following points in mind:
<list>
<item>Make sure you target the right distribution in your
<file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
- testing this is <tt>testing-security</tt>. Do not target
+ testing this is <tt>testing-security</tt>, and for the previous
+ stable release, this is <tt>oldstable-security</tt>. Do not target
<var>distribution</var>-proposed-updates!
<item>Make sure the version number is proper. It must be greater
not build those. This point applies to normal package uploads as
well.
- <item>Always build with full source (use the <tt>-sa</tt> option
- for <prgn>dpkg-buildpackage</prgn>).
+ <item>If the upstream source has been uploaded to
+ security.debian.org before (by a previous security update), build
+ the upload without the upstream source (<tt>dpkg-buildpackage
+ -sd</tt>). Otherwise, build with full source
+ (<tt>dpkg-buildpackage -sa</tt>).
<item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
normal archive, otherwise it is not possible to move the security
exactly meet the team's requirements, it will cause many problems and
delays in dealing with the unwanted upload.
<p>
+<em>DO NOT</em> upload your fix to proposed-updates without
+coordinating with the security team. Packages from
+security.debian.org will be copied into the proposed-updates directory
+automatically. If a package with the same or a higher version number
+is already installed into the archive, the security update will be
+rejected by the archive system. That way, the stable distribution
+will end up without a security update for this package instead.
+<p>
Once you have created and tested the new package and it has been
approved by the security team, it needs to be uploaded so that it can
be installed in the archives. For security uploads, the place to