[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [jbj@redhat.com: Re: freshmeat editorial about package management security issues]



On Tue, 9 May 2000, jeff covey wrote:

> Jeff sent his reply to me only.  Mine is not to wonder why; mine is
> just to forward it to everyone else.  :)

I think given what Jeff said I'd just like to mention basically the key
point in the list thread I mentioned.

RedHat has a single (hopefully) well secured signing key that can only be
used for packages that they produce in house. This is feasable for them
because their development is concentrated in one physical location, and
they don't have the constantly changing archive like we do

Debian has a similar key kept by the Security Team, but it is infeasable
to sign every official pacakge that is created with this key, particularly
since there are hundreds of new packages produced every single day. Though 
we have been talking about signing full releases with this key.

So, in the Debian situation the next logical option is to use the
maintainers personal key for signatures. This brings up the really
interesting question of 'who should sign a package'. With some 500 keys
signing keys the security of the whole scheme is in question. It is
entirely possible to trojan an important package like libc using the most
weakly secured key out of the 500.

This same problem can be applied to upstream source packages too. If
someone downloads a package they can check the signature, but they also
have to *check the key*.

The main point here is that just slapping a signature on packages does not
necessarily make them as safe as the cryptosystem being used, or any safer
than not having a signature.

Jason




Reply to: