Re: Signing Packages.gz
On Mon, 3 Apr 2000, Anthony Towns wrote:
> No, obviously. But as things turn out, at any one time, Debian doesn't
> have all that many (known) security bugs. If you don't have to choose any
> /one/ time though, and can select the worst instance of netbase, and the
> worst instance of make, and the worst instance of mh, and so on, you can
> come up with security holes or grave bugs in a lot of packages. (There
> are 166 packages with urgency=high uploads on my system, for example)
[..]
> Yes. But not every collection of stuff put together by Debian maintainers is
> something Debian ships.
I think this is the key point against .deb signatures as an end-user
verfification scheme. It is a very good point.
> And if someone, like Corel, or Storm, or whoever wants to take bits from
> Debian and add bits themselves, all they have to do is generate a Packages
> file, sign it, and make the public key available. This isn't limiting
> anyone to What-Debian-says-goes, at all. At least as far as I can see.
We could also create a bit of a web of trust, like in SSL - we can use our
security key to sign Corel's key, etc so people know they are not jus J
Random Hacker.
> [0] If you really wanted to avoid this *without* changing dpkg (you only
> need to change Apt to verify signed Packages files) you could have
> Apt memorize the various keyrings and such, and write them back
> before quitting. postinst's which fork() and sleep for an hour or
> so, could probably get around this though. Hmmm. There's probably
> no real way of doing this, actually.
Verifying of things from Package files is clearly the responsibility of
APT, dpkg cannot do it.
Jason
Reply to: