Re: Signing Packages.gz
Anthony Towns <email@example.com> writes:
> The only reason not to trust a key dinstall uses explicitly for signing
> Packages is if you believe dinstall is compromised. If you believe that,
> then you shouldn't be downloading .deb's *ever*, because you're immediately
> running *untrusted* scripts as root on your systems.
That's just the point: the security of a singly-signed Packages.gz
would not be much higher than that of the ftp sites themselves.
Nothing to win, here.
> All this FUD about "no, no, we can't do that, it's not
> secure!" is, well, just that. *Nothing* is absolutely `secure', some
> things just have fewer or different exploits than others.
Of course. But implementing a scheme that does give only marginally
more security may not be worth the effort.
> > Packages should come with their *.changes file, and dpkg should have an
> > option to verify the signature of individual packages.
> Note that this makes debian-keyring a more or less standard package.
Either that, or just let dpkg Recommend it. If it is not installed,
package verification is not available.
> Note that it requires you to trust everyone in that keyring with
> every aspect of your system.
That's already the case, isn't it? Signed packages give you the
benefit, that you'll *only* have to trust the maintainers you install
packages from - not every man-in-the-middle.
> Note that this doesn't help with revoking signatures: if some idiot
> decides that being a Debian maintainer should give him the right to 0wn
> all the machines that use his package; then gets thrown out; he can still
> use his key to sign packages that'll be happily installed by anyone with
> an out of date debian-keyring.
Indeed. But I am sure that this fact will get big coverage on the
lists and the websites. Debian has handled security leaks in other
packages well - this is just a leak in the package system that
updating debian-keyring will plug, nothing else.
> If he can gain control of an ftp mirror, he can keep updating the
> debian-keyring.deb to include his key, and keep "maintaining" any
> packages he likes.
No, see below.
> It also leads to something of a chicken-and-egg situation. It's much
> easier to verify a *single* key than that every one of five-hundred of
> the things is uncompromised. (It can be signed by previous versions of
> itself, it can be widely published in Debian books, it can be signed by
> the ftp team, etc)
The solution is to have one master key (in the hands of a highly
trusted person) that is treated like your single key (published
everywhere). Every developer's key has to be signed by at least by
this key. If one trusts this key, the confidence into keys signed by
it is quite high. Additionally, I can verify keys by other means (e.g.
those of developers living in my vicinity).
Corrupting the debian-keyring package is useless, since the attacker
will not be able to put valid (signed by master) keys into it.