Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 10 Aug 2005, Jeremy Blosser (emrys) wrote:
> On Aug 10, Eric Sandall [eric AT sandall.us] wrote:
<snip>
> > 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).

Correct. I was typing while slightly distracted, sorry.

> 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.

I'd go with if it's signed by a key that has already been verified
with the above methods and matches two other methods then we can trust
it. The reason I still include two other methods is the owners of the
key we trust may not be doing as much diligence in checking as we are
planning/wanting.

> 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.

I'd like all the prior keys to be verified this way, if possible. If
someone would care to go through the vender-provided keys and file
bugs on the keys that still need verifying that'd be great (include me
in CC if you would and it should probably be filed under Security or
Quality Assurance, IMO).

<snip>
> > 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?

While this would be good for security reasons it may delay (and
possibly discourage developers with already little free time) spells
being updated due to the extra checks. It may also encourage gurus to
continue using md5sums as the 'lazy' way to update a package. While
the following is not a valid reason, people are used to easily and
quickly updating packages and, for the users, seeing package updates
the same day (sometimes within minutes) of a version release. Granted,
some well-thought packagers already provide the necessary methods to
verify tarballs, but the majority do not.

Is it worth the (perceived?) extra overhead for the extra security?

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+rruHXt9dKjv3WERAlkyAJ0RupjgXY0iZG3FmiNtqVCNCXpMnQCff13P
V71sntHcMUzvfbqvkRgUkIM=
=pqpO
-----END PGP SIGNATURE-----