7.4. Debian Security Build Infrastructure
Since Debian is currently supported in a large number of architectures, administrators sometimes wonder if a given architecture might take more time to receive security updates than another. As a matter of fact, except for rare circumstances, updates are available to all architectures at the same time.
Packages in the security archive are autobuilt, just like the regular archive. However, security updates are a little more different than normal uploads sent by package maintainers since, in some cases, before being published they need to wait until they can be tested further, an advisory written, or need to wait for a week or more to avoid publicizing the flaw until all vendors have had a reasonable chance to fix it.
Thus, the security upload archive works with the following procedure:
Someone finds a security problem.
Someone fixes the problem, and makes an upload to security-master.debian.org's incoming (this someone is usually a Security Team member but can be also a package maintainer with an appropriate fix that has contacted the Security Team previously). The Changelog includes a testing-security or stable-security as target distribution.
The upload gets checked and processed by a Debian system and moved into queue/accepted, and the buildds are notified. Files in here can be accessed by the security team and (somewhat indirectly) by the buildds.
Security-enabled buildds pick up the source package (prioritized over normal builds), build it, and send the logs to the security team.
The security team reply to the logs, and the newly built packages are uploaded to queue/unchecked, where they're processed by a Debian system, and moved into queue/accepted.
When the security team find the source package acceptable (i.e., that it's been correctly built for all applicable architectures and that it fixes the security hole and doesn't introduce new problems of its own) they run a script which:
installs the package into the security archive.
updates the Packages, Sources and Release files of security.debian.org in the usual way (dpkg-scanpackages, dpkg-scansources, ...).
sets up a template advisory that the security team can finish off.
forwards the packages to the appropriate proposed-updates so that it can be included in the real archive as soon as possible.
This procedure, previously done by hand, was tested and put through during the freezing stage of Debian 3.0 woody (July 2002). Thanks to this infrastructure the Security Team was able to have updated packages ready for the apache and OpenSSH issues for all the supported (almost twenty) architectures in less than a day.
7.4.1. Developer's guide to security updates
