Public SourceMage Discussion List

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

On Aug 10, Seth Alan Woolley [seth AT positivism.org] wrote:
> Secondly, I preferred SOURCE_GPG over SOURCE_HASH to the extent that if 
> both methods are available to the spell writer, that they should select 
> SOURCE_GPG as the method because it completes the integrity chain back 
> to the original author (which can go further, but our responsibility is 
> to get it at least back to the original author).  Once the key is added, 
> each update carries with it further guarantees of trust -- a MIM 
> security attack on older, more used keypair chains is more and more 
> difficult even without initial verification.  With HASHes we tend to not 
> get it from a source which has an increasing level of security -- each 
> new hash is received under similar MIM vulnerable circumstances.
> 
> If the hash were gpg signed, though, this concern wouldn't be there, 
> however, GPG is still more preferred than the HASH in a non-security 
> sense since spell updates require even less effort on each subsequent 
> update.
> 
> And moreover, the ability to rely on gnupg to update hashes used in PGP 
> helps future proof the API.
> 
> Since we publish the keys we use to verify the sources the paranoid even 
> have the ability to self-check our verification, which makes us a very 
> unlikely target for somebody trying to use us as a vector for attack.  
> They'd be exposed pretty darn quick unless they could attack both us 
> (and every other gpg publishing distro) and the download site at the 
> same time.  This element of peer review gives us extra protection.  
> 
> Incorrect hashes though tend to be "oh that's a mistake" or "oh we 
> updated that tarball".  When this happens in a PGP system, you've got a 
> more serious problem than a mistake most of the time.

All of these are great reasons to include vendor keys, but don't apply to
guru-signed spells, which have the same vulnerability at the point we get
the source and sign/hash it.  In either case we get a tarball and then
"stamp" it, the stamp method isn't relevant to the fact the integrity chain
was broken.

> So having said that, yes, we should be diligent to check our public keys 
> just because of the nature of not wanting to have to do a brown-bag 
> update of a vendor pgp key, but it is designed to have some amount of 
> self-protection built into it.  I'm aware of no other distro with an 
> implementation this well-designed (ok, well, I lead design of it, so I'm 
> biased ;)).
> 
> One possible way to make it easy for gurus is to not have gurus do the 
> checking.  They can do very basic checks enough to satisfy themselves 
> and commit to devel grimoire with a WIP, at which point it should never 
> hit test until a separate key review committee can approve it.  This 
> could be composed of trusted members of the community that don't need to 
> be coders themselves.  Maybe they have extensive PGP experience and can 
> follow the steps necessary to verify a public key, including phone 
> calls, email lists, person-to-person contact, following a standard 
> agreed upon and interpreted by members of the specific committee.
> 
> This puts the pressure off of coders who might not have the time to 
> worry about such measures, and yes, they should update our wiki with all 
> the methods used to validate each key.

I think this makes a lot of sense for vendor keys, and I'd be willing to
help with this if necessary.  I'm already trying to get us verification of
all the GNU software keys en masse from the ftp.gnu.org master maintainer,
which should help us convert a lot of core system stuff at once with high
verifiability.

But I don't think we have the resources to take the time to have a central
committee do verification and signing of spells we don't have vendor keys
for.  I still prefer a model where we provide at least minimal verification
(check a vendor-provided hash from multiple sources if we can, if not, do
whatever else is at least reasonably possible and still maintain a quick
update turnaround) and then somehow have the hash/signing method used
reflect to users the level of certainty we were able to establish so they
can at least choose their own risks.

If we decide we still always prefer to guru-sign updates instead of using a
strong hash, maybe we should add some kind of confidence score to the API
so that users can set a minimum threshold of verifiability they're willing
to accept.  Things we have vendor keys for would get the highest score
since they are known good back to upstream, other things would be less,
things without a vendor key but that we've done some verification on would
have a lower score, things got this from the master ftp site but have no
means to verify is what upstream meant and can only verify the user got the
same version we saw would have an even lower score, and the existing
"ignore" for things like CVS checkouts could have a 0 score.  The existing
settings for what to do with a bad/missing md5/sig could be repurposed or
extend to handle this as well.

I agree we're already way ahead of other distros here, it would be great if
we can keep it going and have a top-to-bottom solid implementation others
can use as a model.

Attachment: pgpKcZMKK8Xj3.pgp
Description: PGP signature