Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] verifying gpg keys

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] verifying gpg keys
  • Date: Thu, 11 Aug 2005 09:34:48 -0700

On Thu, Aug 11, 2005 at 01:20:13AM -0500, Jeremy Blosser (emrys) wrote:
> 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.

Exactly correct -- "guru-signed" spells are roughly equivalent to
sha1sum.

>
> > 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 suggest we use sha1sum of the compressed tarball and put that after
SOURCEn_HASH=sha1:

Guru-signed is roughly equivalent though, and I don't want people to not
do guru signing just because people might confuse it with vendor-signed.

We could make a spell with an index of verified vendors that contains a
list of files in a directory with the files named to match the key
fingerprint. Before we run the gpg check we can check the index and
print a message about how thoroughly we verified the key (in either
vendor or guru case) and how sources are signed with that specific key
(vendor or guru signing). If the index is empty, we can print a
warning. That way if an error pops up during verification they can tell
if it's a guru signature error or if the vendor provided a bad signature
so they know where to go from there.

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

We could have this score integrated 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.

Agreed.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpT9MR4moHr4.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page