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: seth AT swoolley.homeip.net
  • 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: Sun, 13 May 2007 21:20:08 -0700

On Sat, May 12, 2007 at 02:46:43PM -0500, Jeremy Blosser wrote:
> 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.

You would be correct if you weren't asserting something when you did the
"sign"
operation on somebody's key. In PGP, you create a web of trust and assign a
trust value when you do that.

There's a difference between signing a key with a trust level (what you
assert) and signing something else.

It's not the same: http://www.gnupg.org/gph/en/manual.html#AEN335

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

I was comparing the two separately. Of course storing the signature
locally gets the same advantages storing a hash locally gets you.
(locally as in within-grimoire).

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

They certainly aren't equivalent (as I stated above), which was my
point. You're saying some people don't see the distinction, which isn't
material to my point that some people do see the distinction.

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

But that doesn't invalidate my point that once they have both those
you're owned regardless of either method used, so yes, it does moot it
to the extent that the sophistication of the attacker is high enough to
pull off the stunt, they're probably going to go for as many
verification methods they can. There's a chance they may not, so it's
not a complete moot, as you say, but it doesn't gain you much in theory.

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

I'd only support it as an optional supplement, or with a way to let me
specify that in the sorcery config. I'm sure you're agreeable to that.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page