Goswin von Brederlow wrote: > "Julian Mehnle" <[EMAIL PROTECTED]> writes: > > We could use a revocation list where signatures of packages with > > known security holes are listed as being revoked. Of course, you'd > > need to be online to check it when installing/updating packages. > > And the revocation list would best be served from a server that's > > secure and separate from the archive servers to make attacks against > > it a bit more difficult. > > And how do you make sure the revokation list isn't compromised (kept > in the state it was a few days ago)? Its the same problem as with the > Packages/Release.gpg files.
The revocation list would need to be signed with a special private key that is stored on a non-networked machine. It's not too often that signatures of old packages need to be revoked. Probably mostly just whenever the security team releases a security-fixed package (of course also on some other occasions). Of course, such a package revocation list brings all the problems that other types of revocation lists, e.g. SSL certificate revocation lists, have. But as proven by VeriSign & Co., these problems can be successfully mastered. > That the one (two) big argument for signed debs: ease of use and > transparency. Not exactly. Also, individual signed debs could be downloaded[1] and verified *individually*. No need for Packages/Release.gpg files. [1] E.g. from http://wiki.debian.net/?DebianKDE or http://people.debian.org/~$developer/