tags 512620 + pending thanks Hi,
Thanks for the patch. I applied it to SVN. - Lucas On 22/01/09 at 11:41 +0100, Thijs Kinkhorst wrote: > Package: developers-reference > Severity: wishlist > Tags: patch > > Hi, > > Please find attached a patch to update the section on handling security > issues. I tried to bring some things more up to date, added a section on > the tracker, and added emphasis on the checks needed before you upload a > package. > > I'm available for any comments or suggestions you have to improve it further. > > thanks, > Thijs > Index: pkgs.dbk > =================================================================== > --- pkgs.dbk (revision 5767) > +++ pkgs.dbk (working copy) > @@ -828,15 +828,13 @@ > fixing them themselves, sending security advisories, and maintaining > <literal>security.debian.org</literal>. > </para> > -<!-- information about the security database goes here once it's ready --> > -<!-- (mdz) --> > <para> > 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; as soon as possible. <emphasis > -role="strong">DO NOT UPLOAD</emphasis> any packages for > <literal>stable</literal>; > - the security team will do that. Useful information includes, for example: > +role="strong">DO NOT UPLOAD</emphasis> any packages for > <literal>stable</literal> > +without contacting the team. Useful information includes, for example: > </para> > <itemizedlist> > <listitem> > @@ -871,6 +869,28 @@ > </para> > </listitem> > </itemizedlist> > +<para>As the maintainer of the package, you have the responsibility to > +maintain it, even in the stable release. You are in the best position > +to evaluate patches and test updated packages, so please see the sections > +below on how to prepare packages for the Security Team to handle.</para> > + > +<section id="bug-security-tracker"> > +<title>The Security Tracker</title> > +<para> > +The security team maintains a central database, the > +<url id="http://security-tracker.debian.net/"; name="Debian Security > Tracker">. > +This contains all public information that is known about security issues: > +which packages and versions are affected or fixed, and thus whether stable, > +testing and/or unstable are vulnerable. Information that is still > confidential > +is not added to the tracker. > +</para> > +<para> > +You can search it for a specific issue, but also on package name. Look > +for your package to see which issues are still open. If you can, please > provide > +more information about those issues, or help to address them in your package. > +Instructions are on the tracker web pages. > +</para> > + > <section id="bug-security-confidentiality"> > <title>Confidentiality</title> > <para> > @@ -940,6 +960,10 @@ > requested: the problem has been known for a while, or the problem or exploit > has become public. > </para> > +<para> > +The Security Team has a PGP-key to enable encrypted communication about > +sensitive issues. See the <url > id="http://www.debian.org/security/faq.en.html#contact"; > +name="Security Team FAQ"> for details. > </section> > > <section id="bug-security-advisories"> > @@ -1076,7 +1100,8 @@ > <itemizedlist> > <listitem> > <para> > -Target the right distribution in your <filename>debian/changelog</filename>. > +<emphasis role="strong">Target the right distribution</emphasis> > +in your <filename>debian/changelog</filename>. > For <literal>stable</literal> this is <literal>stable-security</literal> and > for testing this is <literal>testing-security</literal>, and for the previous > stable release, this is <literal>oldstable-security</literal>. Do not target > @@ -1086,67 +1111,58 @@ > </listitem> > <listitem> > <para> > -The upload should have urgency=high. > +The upload should have <emphasis role="strong">urgency=high</emphasis>. > </para> > </listitem> > <listitem> > <para> > Make descriptive, meaningful changelog entries. Others will rely on them to > -determine whether a particular bug was fixed. Always include an external > -reference, preferably a CVE identifier, so that it can be cross-referenced. > -Include the same information in the changelog for > <literal>unstable</literal>, > -so that it is clear > -that the same bug was fixed, as this is very helpful when verifying that the > -bug is fixed in the next stable release. If a CVE identifier has not yet > been > -assigned, the security team will request one so that it can be included in > the > -package and in the advisory. > +determine whether a particular bug was fixed. Add <literal>closes:</literal> > +statements for any <emphasis role="strong">Debian bugs</emphasis> filed. > +Always include an external reference, preferably a <emphasis > role="strong">CVE > +identifier</emphasis>, so that it can be cross-referenced. However, if a CVE > +identifier has not yet been assigned, do not wait for it but continue the > +process. The identifier can be cross-referenced later. > </para> > </listitem> > <listitem> > <para> > -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 <literal>dpkg --compare-versions</literal>. Be careful not to > -re-use a version number that you have already used for a previous upload. > For > -<literal>testing</literal>, there must be a higher version in > -<literal>unstable</literal>. If there is none yet (for example, if > -<literal>testing</literal> and <literal>unstable</literal> have the same > -version) you must upload a new version to <literal>unstable</literal> first. > +Make sure the <emphasis role="strong">version number</emphasis> is proper. > +It must be greater than the current package, but less than package versions > in > +later distributions. If in doubt, test it with <literal>dpkg > +--compare-versions</literal>. Be careful not to re-use a version number that > +you have already used for a previous upload, or one that conflicts with a > +binNMU. The convention is to append > +<literal>+</literal><replaceable>codename</replaceable><literal>1</literal>, > e.g. > +<literal>1:2.4.3-4+etch1</literal>, of course increasing 1 for any subsequent > +uploads. > </para> > </listitem> > <listitem> > <para> > -Do not make source-only uploads if your package has any binary-all packages > (do > -not use the <literal>-S</literal> option to > -<command>dpkg-buildpackage</command>). The <command>buildd</command> > -infrastructure will not build those. This point applies to normal package > -uploads as well. > -</para> > -</listitem> > -<listitem> > -<para> > Unless the upstream source has been uploaded to <literal>security.debian.org > -</literal> before (by a previous security update), build the upload with full > -upstream source (<literal>dpkg-buildpackage -sa</literal>). If there has > been > -a previous upload to <literal>security.debian.org</literal> with the same > -upstream version, you may upload without upstream source (<literal> > -dpkg-buildpackage -sd</literal>). > +</literal> before (by a previous security update), build the upload <emphasis > +role="strong">with full upstream source</emphasis> > (<literal>dpkg-buildpackage > +-sa</literal>). If there has been a previous upload to > +<literal>security.debian.org</literal> with the same upstream version, you > may > +upload without upstream source (<literal> dpkg-buildpackage -sd</literal>). > </para> > </listitem> > <listitem> > <para> > -Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in > the > +Be sure to use the <emphasis role="strong">exact same > +<filename>*.orig.tar.gz</filename></emphasis> as used in the > normal archive, otherwise it is not possible to move the security fix into > the > main archives later. > </para> > </listitem> > <listitem> > <para> > -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 <xref linkend="server-machines"/> ) or > -setup a chroot (see <xref linkend="pbuilder"/> and <xref > -linkend="debootstrap"/> ). > +Build the package on a <emphasis role="strong">clean system</emphasis> 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 > +<xref linkend="server-machines"/> ) or setup a chroot (see > +<xref linkend="pbuilder"/> and <xref linkend="debootstrap"/> ). > </para> > </listitem> > </itemizedlist> > @@ -1179,7 +1195,7 @@ > </para> > <para> > Once an upload to the security queue has been accepted, the package will > -automatically be rebuilt for all architectures and stored for verification by > +automatically be built for all architectures and stored for verification by > the security team. > </para> > <para> -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
