Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Aug 18, Seth Alan Woolley [seth AT positivism.org] wrote:
> On Fri, Aug 19, 2005 at 01:08:01AM +0200, Karsten Behrmann wrote:
> > On Thu, 18 Aug 2005 09:21:53 -0700, Andrew wrote:
> > > Good point. Its also (potentially) a security risk, since if the key
> > > was described as ../../kernels/linux/foo.gpg, if the key wasnt found
> > > there (say it was renamed or moved) the code would look in the grimoire
> > > directory with that path appended to it. In that case it would look
> > > outside the grimoire into a possibly unsecured directory, the spell 
> > > would
> > > use an incorrect gpg key and validate a possibly compromised source/sig.
> > > Unlikely, but worth mentioning.
> > 
> > Apropos security risks in gpg signing:
> > Just a thought, I'm almost sure it has to be resolved, but I thought 
> > I'd mention it: Do we specify a keyring as well as a signer's 
> > fingerprint or at least ID? Otherwise, couldn't the new gnu dev that 
> > just got into gnu.gpg sign off a compromised binutils? The basic point 
> > here is that maybe we should keep the keyrings as collections to be 
> > referenced, but not as authorities on their own.
> 
> They have access to our source code repository, too.

He said gnu.gpg, not gurus.gpg.

For someone to compromise an app that's referencing the gnu.gpg keyring for
signature checking THROUGH the keyring, they would need to:

1a) get control of an existing key inside of gnu.gpg that we have already
decided is ok to use
OR
1b) get a new key inside of gnu.gpg and get us to accept it
2a) compromise the tarball
AND
2b) generate a compromised signature for the tarball and get it published at
the SOURCEn_URL we're using to get the release signature

1a) is out of our control, it is solely determined by the access security
around the private half of the relevant keypair.
1b) is a risk in any system like this and it's the main thing that we need
to worry about.  We need to make sure we only use keys that are good.
However, to your point, no, some new gnu dev wouldn't automatically have us
using their key, we'd have to add it to the version of that keyring that
we're using.  If/how we add it is the subject of the recent threads around
how we verify keys.

2a) and 2b) are out of our hands as well, and it's worth noting that if the
upstream security breaks down to the point that an attacker has control of
the release tarball AND the private signing key, we can't do a thing about
it.

Our integrity checks are designed to catch the "normal" situation where
someone gets control of the upstream distribution site and replaces the
tarball with a compromised one.  If they only manage this much, the
signature check will fail, and we'll see it.  They may also try to replace
the signature on the upstream server, but unless they have the private key
needed to generate a real signature using a key in the local keyring we're
referencing, we're going to notice that as well.

If they manage to compromise the tarball and still get upstream to sign it
we also can't do anything.  Remember, we aren't guaranteeing the source
isn't trojaned or going to run rm -rf /, we're just verifying it's the same
tarball that upstream released.

Attachment: pgp0GIlZaYXZc.pgp
Description: PGP signature