On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: > Use 1: I have this deb in my apt-move mirror and I want to know if it > was compromised on yesterdays breakin > Boot a clean system with debian keyring and check all deb > signatures. Find some don't pass because they were signed with keys that have been removed from the keyring. > Use 2: I have this Ubuntu CD and want to know which debs are from > debian and which got recompiled > Look for all debs that have a deb signature of the debian archive > (to be added to dinstall at some point). Never to be added, because it would change the .deb from that which was originally uploaded, for no benefit. > Use 3: The debian servers were compromised and the security team takes > too long to check the archive for my taste > Being a normal user I obviously have no mail archive of all the > old changes files laying around so that road is closed. But everyone > has a Debian stable CD with keyring. See Use 1. And see why it doesn't work. Not to mention keys added since stable released, and packages uploaded by those maintainers. More than just keys removed from the keyring, there's the issue of keys being compromised -- it's not even unknown for developers to post secret keys to mailing lists -- the issue that a package that's once been in the archive may well by now have known security holes (which is why we have security.debian.org after all), and that this is entirely moot anyway since the vast majority of packages can't be verified by dpkg-sig. > > buildd.debian.org gives full logs, to developers or users. > While the log contains the md5sum of each build deb it does not > contain any signature against tampering. No, that's what the signed .changes file is for. > Tampered debs can be uploaded by sending a fake mail to the admin and > filtering out his responce. A deb signature of the buildd and a > subsequent dak check would prevent this. So would having the buildd sign the mails to the buildd admin, which would have the benefit of not giving a couple of dozen completely untrustworthy keys special access to the archive. (AIUI, signed mails to the admin are on the TODO list; at present buildds don't have keys of their own at all) > >> something that provides DD-to-user package signatures at least in some > >> cases is very desirable indeed. > > debian-devel-changes provides this. > That covers only the sourcefull uploads and the arch specific -changes > lists are not archived and therefore useless for non constant > monitoring. Far easier to fix that, than retrofit 150G of debs to a flawed and redundant scheme like this. Cheers, aj
Attachment:
signature.asc
Description: Digital signature