RE: Revocation list for old packages with security holes
Goswin von Brederlow wrote:
> "Julian Mehnle" <lists@mehnle.net> 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/
Reply to: