Public SourceMage Discussion List

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

On Aug 10, Eric Sandall [eric AT sandall.us] wrote:
> On Wed, 10 Aug 2005, Jeremy Blosser (emrys) wrote:
> > Now that more gurus are converting spells to use gpg checking, I want to
> > suggest that we develop some kind of standards around the verification
> > expectations before we include a vendor key or sign a spell with a guru
> > key.  Right now it's just up to the gurus, but given the variance in
> > familiarity with gpg concepts, I think it's important we provide some
> > guidance so we're actually protecting our users with these schemes.
> >
> > The big advantage of vendor-provided keys and signatures is that updating
> > the spell to a new upstream version just means changing the version 
> > number,
> > there's no per-version signature or hash update/verification.  The 
> > downside
> > of this is that if we just accept a key from the upstream server without
> > verifying it, and that key was itself compromised, we may have it for
> > multiple versions before realizing it.  Given that the vendor keys often
> > are found on the same upstream server the source comes from, this is a 
> > real
> > risk.  When we provide an upstream key in the grimoire we are representing
> > to users that we trust that key to be an authenticator that a source
> > tarball is not compromised.
> >
> > I'm not suggesting we need to verify driver's licenses or passports or
> > anything.  But I think we should at least try to verify the key 
> > fingerprint
> > from a few disparate sources/channels.  We discussed this a bit on IRC and
> > noted that usually you can at least get it from a web site and the
> > keyserver, and hopefully you can find some mailing lists posts or archives
> > that also list it.  This isn't a ton of effort, especially since you only
> > have to do it once for each key.
> >
> > Thoughts on this?  What kind of minimum should we try to establish?  I'm
> > going through right now converting a lot of the gnu software to gpg
> > checking, since they provide sigs for all their current software;
> > unfortunately those keys aren't very widespread and it's proving difficult
> > to get external validation for them, so this is also a pragmatic question.
> > I'll probably try mailing the authors for verification if nothing else, I
> > guess.
> 
> I'd say that vendor-provided signatures should be verified with at
> least three of the following methods:
> 
>    1. Signature provided on the site
>    2. Signature from their official mailing lists
>    3. Signature verified via e-mail/mail/phone by a developer of said
>       project
>    4. Signature from keyservers (we usually use pgp.mit.edu)

These work for me, with the note that you meant 'vendor-provided keys', not
signatures, and that for the verification methods, a fingerprint is as good
as a key (the fingerprint is the only thing you can reasonably verify over
the phone, and it's how you do key comparison for verification anyway).

We might add an option 5, which would be that the key is signed by a key we
already trust.  I'm not sure what the metric for 'trust' would be; it could
be enough to be any key that we have verified enough to include, or we
might want more than that.

How do we codify this?  It should be added to the GPG instructions page,
and I would suggest that any time we add a vendor key to the grimoires we
should provide the ways it was verified, just for auditing purposes.  This
probably means there are keys that have been included already that should
be revisited.

> > Guru-signed spells are harder.  We still have to verify the source per
> > release, but we probably should make sure people are doing more
> > verification here than they were probably doing with md5 sums.  Just
> > downloading the source and running md5sum or immediately signing whatever
> > you get is not "verification"; all you're doing is providing verification
> > to users that the (possibly compromised) source they're downloading is the
> > same as the (possibly compromised) source the guru got when they updated
> > the spell.  However, I don't know how per-release verification might work
> > for upstream vendors that don't care to provide something like sigs
> > already.
> 
> This would technically be implausible withour current staff. We don't
> have the resources to audit every release (nor do most other distros)
> for compromises. Perhaps, as a minimum, we can 'require' that gurus
> download, install, and sign tarballs only from the main site (if one
> is available) and not mirrors? That should limit the possible damage
> by only using tarballs that the author (supposedly) put up and not
> from a mirror where the author (presumably) has no control.

I think getting sources from the master for generating any signature or
checksum is something that should definitely be standard.

And while I know we don't have resources to do our own source audits, I
guess I might suggest that there should be a minimum verification that is
done before we as gurus sign a spell.  There's not a real value difference
between guru-signed or guru-checksummed, but there *is* more weight from a
user perspective behind the GPG signature being there, so we should perhaps
use that to let users know the level of verification we've been able to do
for a given release.

Maybe something like: if you can verify the checksum at least 3 of the
same above 4 listed ways, you can guru GPG sign that release.  So, if they
provide a checksum on their website and their mailing list and somewhere
else, you can verify that checksum matches your download and sign it.
If you can't verify the checksum from 3 sources, you should only provide a
checksum in the spell yourself (hopefully something better than md5, but
the new verification lib supports some nice strong ones).  This shouldn't
require more work than we should be doing now, but it does let our users
that care about the differences know that "GPG Signature Verified" means
one level of validation has occurred, while "Checksum Verified" means
something objectively less.  This seems appropriate to me, and helps avoid
giving a false sense of security to users.

Thoughts?

Attachment: pgpB0U3uKTusq.pgp
Description: PGP signature