Hi,
As mentioned in earlier mails and also noted in the manual itself, the
devref is the place where instructions for DD's on providing updates for a
DSA are located. The current instructions in the securing-howto are
outdated and even wrong and continue to confuse people. Please remove it
and refer to the devref, as per attached patch.
Thanks,
Thijs
Index: infrastructure.sgml
===================================================================
--- infrastructure.sgml (revision 8125)
+++ infrastructure.sgml (working copy)
@@ -264,156 +264,15 @@
ready for the apache and OpenSSH issues for all the supported (almost
twenty) architectures in less than a day.
-
<sect1>Developer's guide to security updates
-<p>This mail was sent by Wichert Akkerman to the <url
-id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html";
-name="Debian-devel-announce mailing list"> in order to describe Debian
-developer's behavior for handling security problems in their
-packages. It is published here both for the benefit of developers as
-well as for users to understand better how security is handled in Debian.
+Debian developers that need to coordinate with the security team on
+fixing in issue in their packages, can refer to the Developer's
+Reference section
+<url id="http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security";
+ name="Handling security-related bugs">.
-<p>FIXME: Please note that the up to date reference for this information is
-the <url id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs#bug-security"; name="Debian Developer's Reference">, this section will be
-removed in the near future.
-<sect2>Coordinating with the security team
-
-<p>If a developer learns of a security problem, either in his package
-or someone else's he should always contact the security team (at
[email protected]). They keep track of outstanding security
-problems, can help maintainers with security problems or fix them
-themselves, are responsible for sending security advisories and
-maintaining security.debian.org.
-
-<p>Please note that security advisories are only done for release
-distributions, not for testing, unstable (see <ref id="sec-unstable">)
-or older distributions (see <ref id="sec-older">).
-
-<sect2>Learning of security problems
-
-<p>There are a few ways a developer can learn of a security problem:
-
-<list>
-<item>he notices it on a public forum (mailing list, website, etc.).
-<item>someone files a bugreport (the <em>Security</em> tag should be
-used, or added by the developer).
-<item>someone informs him via private email.
-</list>
-
-<p>In the first two cases the information is public and it is important
-to have a fix as soon as possible. In the last case however it might
-not be public information. In that case there are a few 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 problem is severe (remote exploitable, possibility to gain root
- privileges) 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 (the developer should make
-sure he tells the security team that the information cannot be
-disclosed).
-
-<p>Please note that if secrecy is needed the developer can also not
-upload a fix to unstable (or anywhere else), since the changelog
-information for unstable is public information.
-
-<p>There are two reasons for releasing information even though secrecy
-is requested/required: the problem has been known for too long, or
-the information becomes public.
-
-<sect2>Building a package
-
-<p>The most important guideline when making a new package that fixes a
-security problem is to make as few changes as possible. People are
-relying on the exact behavior of a release once it is made, so any
-change made to it can possibly break someone's system. This is
-especially true of libraries: the developer must make sure he never
-changes 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 backported. Generally upstream
-maintainers are willing to help if needed, if not the Debian Security
-Team might be able to help.
-
-<p>In some cases it is not possible to backport a security fix, for
-example when large amounts of source code need to be modified or
-rewritten. If that happens it might be necessary to move to a new
-upstream version, but it should always be coordinated with the security team
-beforehand.
-
-<p>Related to this is another important aspect: developers must always
-test your change. If there is an exploit the developer should try if
-it indeed succeeds on the unpatched package and fails on the fixed
-package. The developer should try normal usage as well, sometimes a
-security fix can break normal use subtly.
-
-<p>Finally a few technical things for developers to keep in mind:
-
-<list>
-<item>Make sure you target the right distribution in your debian/changelog.
- For stable this is stable-security and for testing this is
- testing-security. Do not target <codename>-proposed-updates.
-
-<item>Make sure the version number is proper. It has to be higher than the
- current package, but lower than package versions in later
- distributions. For testing this means there has to be a higher version
- in unstable. If there is none yet (testing and unstable have the same
- version for example) upload a new version to unstable first.
-
-<item>Do not make source-only uploads if your package has any binary-all
- packages. The buildd infrastructure will not build those.
-
-<item>Make sure when compiling a package you compile 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 try a debian.org machine (see http://db.debian.org/machines.cgi)
- or set up a chroot (the <package>pbuilder</package> and
- <package>debootstrap</package> packages can be helpful in that
- case).
-
-</list>
-
-<sect2>Uploading security fixes
-
-<p>After the developer has created and tested the new package it needs to be
-uploaded so it can be installed in the archives. For security uploads
-the place to upload to is
-ftp://security-master.debian.org/pub/SecurityUploadQueue/ .
-
-<p>Once an upload to the security queue has been accepted the package will
-automatically be rebuilt for all architectures and stored for
-verification by the security team.
-
-<p>Uploads waiting for acceptance or verification are only accessible by
-the security team. This is necessary since there might be fixes for
-security problems that cannot be disclosed yet.
-
-<p>If a member of the security team accepts a package it will be installed
-on security.debian.org as well as the proper <codename>-proposed-updates
-in ftp-master or non-US archive.
-
-<sect2>The security advisory
-
-<p>Security advisories are written and posted by the security team. However
-they certainly do not mind if a maintainer can supply (part of) the text
-for them. Information that should be in an advisory is described in
-<ref id="dsa">.
-
-
<sect id="deb-pack-sign">Package signing in Debian
<p>This section could also be titled "how to upgrade/update safely
