Bug#512620: update section on handling security issues
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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: