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