Re: Signing Packages.gz

[Jason Gunthorpe <jgg@ualberta.ca>]

On Sun, 2 Apr 2000, Marcus Brinkmann wrote:

> This is a seperate problem. I agree that this should not be the case, but it
> has no place in this discussion. If individual developer keys are
> compromised, we have a problem no matter what. Developers should not store
> secret keys on net connected machines, point.
> 
> However, this only affects the developers packages, not the whole archive.
                                                      ^^^^^^^^^^^^^^^^^^^^^
 
GAH!? Don't you see that isn't true?? Look, a hack attempt would go like
this.

  1) Break root on master
  2) Use that to break user account on developer victum (any will do)
     (Hint: I have already shown that torsten at least could be 
      attacked quite easially)
  3) Steal PGP key
  4) Use stolen PGP to form new glibc package with trojan, sneak into
     archive using #1

If #1 is possible than #3 and #4 sure as heck will be too! Furthermore,
this is lethal, it can effect both stable, unstable, distributed CDs -
everything! What is worse, once you know it has happened - how do you
determine which PGP key has been stolen? You have to *manualy* go
through every single package and check the signer by hand to make sure it
is all correct. Only someone very well versed in the ftp archive can do
this.

In fact, any time a developer is forced to revoke his key for any reason
it calls the security of 'fixed' things we have distributed (stable
basically) into question, you can't quite tell if that CD out there is
legit or modified. This is a very serious weakness. Think about that, it
is important.

With a dinstall key it goes like this
  1) Break root on master
  2) Hack archive use dinstall key.

However, an attacker doing this can only ruin unstable, our stable
distribution and all CDs *remain secure* The archive itself is recoverable
because the process above can be done. 

This is also very easially recoverable, we revoke the dinstall key, create
a new one, signed by the security key and automated tools can fix the
situation without hassle. The dinstall key has no permanance (on CDs on
the like) so this isn't a big deal.

With the secure dinstall key things are the best they can be:
  1) Break root on wichert's machine
  2) Steal security key
  3) Break root on master or forge CD's

Now we assume wichert is very carefull with the security key [more
carefull than the average developer] so #2 is very very hard - thus this
is the most secure alternative to the 2 above. But is impossible for use
on a daily basis.

Jason