Re: Revocation list for old packages with security holes
"Julian Mehnle" <lists@mehnle.net> writes:
> 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).
You completly missed the point.
Say something gets revoced, added to the list and the list is signed
and all. But still this stupid transparent proxy of my stupid ISP will
give last month list and I will never know something got revoked.
The same could happen intentionally by an attacker.
> 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.
Yes, you don't need archive the Release.gpg or changes files from the
time the package was released: "ease of use". You can even verify
debian.snapshot.net.
MfG
Goswin
Reply to: