Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] changing hashes / upstream signatures (was: [SM-Commit] GIT changes to master grimoire by Ladislav Hagara (ad0a24226e43aeb1ac12e792c02e31f3011852c4))

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] changing hashes / upstream signatures (was: [SM-Commit] GIT changes to master grimoire by Ladislav Hagara (ad0a24226e43aeb1ac12e792c02e31f3011852c4))
  • Date: Sat, 12 May 2007 14:46:43 -0500

On May 12, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> On Fri, May 11, 2007 at 09:52:35PM +0200, Ladislav Hagara wrote:
> > > Then store the upstream signature for the release in the grimoire
> > > itself.
> > > Is there something preventing this from happening? It's been suggested
> > > many times.
> >
> > So why nobody do it. Let's go.
> > It is not a problem only of "my" spells. It is a problem of all spells.
> > So all developers should store upstream signatures in grimoire.
> > All signatures of all vendor signed spells shoud be stored in grimoire.
> >
> > The only one spell without signature in the grimoire can destroy all
> > SMGL boxes.
> > Hacker/cracker just steals vendor private key (we know nothing about
> > security policy of small project and we download sources and signatures
> > form their sites), modifies sources - added something like "rm -rf /*"
> > to "configure" and signs it.
> >
> > IMHO, better than adding upstream signatures to the grimoire is just
> > add next level of checking of sources.
> > 1st level - vendor/upstream signatures. 2th level - our own signatures
> > or hashes.
> >
> > ---
> > Building XXX
> > Upstream/vendor GPG checking source file XXX.tar.bz2...
> > gpg signature verified!
> > SMGL GPG/HASH checking source file XXX.tar.bz2...
> > FAILURE to verify gpg signature/HASH
> >
> > Sources XXX.tar.bz2 are signed by upstream key/developers of XXX
> > but they are different from sources SMGL developers have tested.
> >
> > Abort? [y]
> > ---

> When you sign a vendor's private key, you also assert to your faith in
> their security policy. It's in the PGP FAQs all 'round the web.

Er, when you sign something you assert only what you claim to assert. This
is the same as the claim that our signing upstream sources somehow asserts
that we've audited them. Our signatures on sources only assert that this
is the same source we got from the upstream initially, and our signatures
on the whole tarball only assert that this is the tarball we intended for
distribution. There's no way our tarball signature on a spell that has an
upstream signature in use is any assertion we trust their security policy
-- we quite definitely don't know their security policy, with perhaps a few
exceptions.

> In any case, theoretical examples are great and all, but you need to
> look at the reality. The reality is that if we include the upstream
> author's key for a spell we get an immense advantage in preventing
> people going 'oh that spell must have been changed and not reversioned'.

Which isn't really relevant to the particular concern being raised, since
we aren't talking about getting rid of the upstream signature or anything.

> A failed signature though is _never_ explainable with simple excuses
> like that. People get in the habit of ignoring bad checksums -- they
> don't ignore invalid signatures.

Eh, it depends on the individual and the frequency of such changes. I've
seen people ignore both plenty of times. I imagine it's safe to say that
if we logged every time someone says "n" to a "verification failed, abort"
prompt in sorcery that it's well more than 50% of the cases, regardless of
the cause of the error.

> And to completely moot your argument: If their key storage security
> policy is bad, you've already got the keys to the house, and our own use
> of their signature for the first version downloaded (where you get your
> sacred hash) is only a little bit less suspicious. Heck, start sending
> emails out in private to posters of the mailing list saying you've got a
> new version out as their identity and provide a non-official url with an
> official signature and you're likely to fool half the people. Once
> you've got the private key for somebody, the game's over already, since
> if you're able to change a primary mirror AND sign falsely, you can just
> wait for the next release cycle and change the signature on the mirror
> with your magic private key a few seconds after release -- then you've
> COMPLETELY compromised both hashes and the PKI.

This doesn't "completely moot" anything, this only asserts that the stealth
case of changing the current version somehow won't happen just because
other things are possible as well. It is still entirely possible for
someone who gets access to the private key and distribution server after a
release to just change the current version and resign it. Depending on the
patience and sophistication of the attacker it's arguably even the most
likely attack.

> Your example is contrived and is a small islet of a complaint in a sea
> of major problems with using straight hashes.

Comparing this issue to the number of issues with hashes might be relevant
if the suggestion was to drop upstream signatures in favor of hashes, but
it isn't. All that's being said is that when we used hashes stored in the
spell we had an added property that the hash was stored in a location
completely separate from the source, and there are benefits to this. Of
course it's true that the original source (and its hash) could have already
been compromised, but we have to start somewhere.

Storing the upstream signature in the grimoire or keeping a hash as a
second-level check *would* guard against the possibility of the upstream
source and signature being compromised after the release. I happen to
agree this is a valid point to be making, and I don't see how it would hurt
us to do either. Whether or not we should actually start doing it is
probably still a matter for more discussion, though.

Attachment: pgpkmBrZ6gr6b.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page