[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How to improve archive verification possibilities for the future



Hi,

first let me say that despite the unfortunate things that have
happened to our servers, Debian is still a very good GNU/Linux
distribution, and I wish to explicitly thank all people who have
participated in the assessment of the damages being done to our
infrastructure, and those who have worked so hard on getting the
compromised machines back online. I sincerely hope that the detailed
analysis of the compromise is published soon.

A few paranoid people, including me, have had the wish to be able to
do some verification on the archive. This has become more urgent with
the compromise since this has shown to all of us how vulnerable we all
are.

I am pretty well aware that a Debian user needs to trust a lot of
people when using the distribution: You'll have to trust the
maintainer and their build systems, the autobuilders and the packages
installed on them. A single trojaned binary on one of the build
systems can easily break the chain of trust from upstream author to
end user, and there is not much we can do against this without major
changes in our build procedures and infrastructure.

However, what we can do is establish trust between our main archive
and the end user. We already try to do this in three different ways:

(1) We have signed Release files which contain md5sums of Packages and
Sources files which in turn contain md5sums of the actual packages.
The Release files currently in the archive are signed with key
38C6029A. It seems like Debian did not publish the policy for handling
of this and other project keys. Some paranoid people thus consider the
possibility of this key having been stored on one of the compromised
machines.

(2) We have signed changes files with contain md5sums of binary and
source packages. These signatures are done by the maintainer or the
respective autobuilder. Unfortunately, we don't seem to keep copies of
all changes files around in a publicly accessible way.

(3) We have signed .dsc files which contain md5sums of source
packages. These signatures are done by the maintainer of the package,
and are - according to my understanding - the only signatures that
currently can be completely verified. However, we don't seem to have a
turn-key solution to actually do this kind of verification.


It looks like the binary packages in the archive cannot be gpg
verified against the uploader's key at the moment because the changes
files are only incompletely archived. There does not seem to be any
cure for this, the damage is done.

But how can we make the current processes better? I would like to
propose some minor changes to the way we handle things like this:

(0) There should be a published policy for all keys that the project
uses for Signatures. This includes suggestions for maintainer keys
that are a little more verbose than Developer's Reference 3.2 - maybe
in the style of debian-keyring's README.

(1) The Release files for stable should be signed with an off-line key
whose private part is not present on any of the project machines.
Stable releases don't happen frequently, so the added complexity is
well worth the trouble, in my opinion.

The Release files for unstable and testing still have to be signed
automatically, but I'd really prefer to have that done by downloading
the file to a non-public machine, signing there and re-uploading.
Additionally, I'd like to have snapshots (for example all four weeks)
to be signed manually with an off-line key.

Since we usually only sign md5sums of actual files (with optionally
more steps of indirection in between), we'd need to keep snapshots of
the files referenced in a signed file (for example, the Packages
files), so that it is possible to verify against a "historic" Release
file to make sure that a big part of the archive is still intact.

(2) We should keep the .changes files around with the binary packages,
preferably in the archive.

(3) We should have packaged scripts available that do the actual
verification steps as a turn-key procedure to be done by people not
adept in scripting.


I'd like to put these things up for discussion. I hope it doesn't
generate a flame war.

Thank you very much for reading.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29



Reply to: