On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote: > On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: > > The whole file --- verifying each entry would take at least three minutes > > on my hardware, and god knows how long on anything moderately old or > > outdated. I certainly wouldn't want to try it on m68k on a regular basis, > > eg. (If doing something just once takes a second; doing it 4000 times > > takes a bit over an hour) > I don't think it is useful to sign the Packages file, because: A signature authenticates the source of a document. That's worthwhile, since verifying the source of a Packages file lets you transitively verify the source of all the packages in a distribution. > > Whose key should be used? Probably a special one just for dinstall, > > that's kept fairly securely by the Novare and -admin folks, and revoked > > regularly. > Any such key would have to be considered insecure, no matter how soon you > revoke it. So the paranoid people still don't trust it, and the other don't > care (probably). Nonsense. 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. If dinstall *isn't* compromised, it's still possible that your favourite FTP site is, in which case all they need to do to compromise your machine is replace a .deb with their own hacked version and let you download it. Automatically signing things is less secure than manually signing things, and you need to do some extra stuff to not have gaping security holes when automatically signing things, but sometimes there isn't that much of a choice. 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. > > There doesn't really seem a huge amount of choice here, to me. > Packages should come with their *.changes file, and dpkg should have an > option to verify the signature of individual packages. There was some > discussion about this in the past. The trick is that security should be > implemented in dpkg(-dev), not somewhere else. This has the advantage that > it works also with individual packages you don't get from an archive source. > It cuold also be used to verify the origin of the package. Note that this makes debian-keyring a more or less standard package. Note that it requires you to trust everyone in that keyring with every aspect of your system. 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. 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. With a dinstall key, the only way he can do this is if he's a member of the ftp team or debian-admin. 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) Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
Attachment:
pgpwoYMKUb8a1.pgp
Description: PGP signature