Migration to APT 0.6

APT version 0.6 adds support for cryptographically verifying the origin of packages. This means that Debian users can ensure that the packages they install are official packages released by the Debian project and have not been tampered with while they were transmitted across the network or stored on mirrors. This verification is designed to counter the following two threats:

Mirror network compromise: An archive mirror might be attacked successfully, and begin to serve compromised packages to users and other mirrors.

Network-layer attacks: Traffic could be redirected and DNS responses could be forged. Thus, an attacker might lure a user (or another mirror) into downloading compromised packages.

The kind of signatures introduced by APT 0.6 do not protect against a compromise of internal Debian infrastructure used to prepare the archive, though. This is similar to what other vendors do: They sign their software with an organization-specific key, but do not document who built the software, or try to cryptographically secure its construction in a publicly verifiable manner.

The two threats mentioned above are deemed important enough to consider the inclusion of APT version 0.6 in the upcoming Debian release, codenamed sarge. However, at this stage of the release process, careful consideration is necessary not to introduce any regressions that would delay the release. Furthermore, some key design decisions behind the archive verification framework are being contested.

Below, we identify potential showstoppers preventing the migration, open questions and provide a list of active and pending tasks. Feel free to mail any corrections and suggestions to fw@deneb.enyo.de; I will update this page as needed.

Some issues must be addressed under all circumstances before Debian can switch to APT 0.6. The list below is expected to be complete. A few items on this list may involve significant work. Progress will be tracked on a page referenced from here once work on a particular item has begun. For the list of smaller tasks being actively worked upon, see the next section. (The separation between showstoppers and more manageable units of tasks is intended to increase parallelism.)

Archive signing touches several parts of Debian's infrastructure. Some persons have to do additional work in the future. We must ask them beforehand if they are willing to do that work, and ensure their cooperation.

A review of the general design decisions, in particular key management and key rollover is needed. Any changes resulting from this discussion, both in client-side software (APT and its frontends) and on the side of the archive, must be documented and implemented.

We must review the implementation in apt-get, and test it. This needs a collection of test archives (see tasks below).

Support from other APT frontends. This needs testing, and probably writing some code. For these tests, the test archive is needed, but it is possible to begin testing the general interaction between APT and the frontends while the key management details have not yet been finalized. (The failure scenarios are rather similar, independently of which approach is chosen in the end.)

If you think this list is incomplete, please fw@deneb.enyo.de because we risk that we run into the problem you foresee (which might invalidate previous work or even put the release of sarge at risk).

The list below is presented in order the tasks should be tackled, not according to their importance. If you want work on any of the items, please send me a short message at fw@deneb.enyo.de. I will update this list accordingly. Note that this list is not complete and is expected to grow once we tackle the showstoppers one after the other.

APT frontends have to be modified to properly support archive signature verification. While most (if not all) frontends continue to work well when recompiled against the APT 0.6 libraries, changes are necessary so that the frontends properly informs the user about potential archive tampering.