Public SourceMage Discussion List

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

On Aug 31, Sergey A. Lipnevich [sergey AT optimaltec.com] wrote:
> Assumptions:
> a1) tarball was not signed by its author(s);
> a2) we're using the same hash function as the signature algorithm, except 
> when
> using signatures the hash is additionally signed, and *only* signature is
> included in the grimoire;

This assumption is the crux of the issue.  As has been said a few times,
one primary motivation for moving to GPG is that we want to offload sorcery
needing to know about the state of the art in hash algorithms.  So a more
proper assumption would be that SOURCE_HASH and GPG are using different
hash algorithms, and the one GPG is using is less vulnerable to hash
collisions.

> s1. The tarball is published, then compromised after we added to the 
> grimoire.
> s2. The tarball is published and compromised immediately.
> s3. The tarball is published and not compromised, but user's local network 
> is
> exploited to make him/her download a compromised copy.
> s4. The tarball is published and not compromised, but user's local network 
> is
> exploited and the user downloads both malicios tarball and modified grimoire
> tarball.
> s5. SMGL site is compromised, the grimoire tarball with hashes/signatures is
> replaced.
> 
> In scenario 1, hash value and a signature would both detect the breach. If
> there's a hash collision. If there's a collision, both hash and signature
> detect nothing. Hash +1, signature +1.

I can't say I definitely know enough about the math of signatures to say if
this is true or not.  But again, this isn't the point.

> In scenario 2, hash value would have to be replaced when the breach is
> discovered. If the tarball is signed by SMGL maintainer, the signature
> has to be replaced, and the key might have to be revoked, and new key
> must be created.  If users disable GPG verification, e.g. because they
> don't have always-on Internet access, or they don't want to use GPG, they
> are running the additional danger on never learning that the tarball is
> tainted. Hash +1, signature +.5 (with .5 subtracted because of the extra
> hassle).

Why would users disable GPG if they don't have always-on internet access?
It's used when casting a spell, which is going to normally be downloading
something anyway.  They may already have the tarball summoned, but if so
they'll also have the vendor sig (from upstream or the grimoire) or the
guru sig (from the grimoire).

Anyway, you're right that if we sign something that was compromised, we
should revoke the signing key and resign everything that previously used
that key.  This can be scripted pretty easily, so I wouldn't call it that
much extra hassle.  It's also worth noting that the problem would have to
be discovered for us to do anything about it, at which point upstream would
likely remove the bad tarball and replace it with a new one with a
different name, or at least definitely a different hash.  This means that
for a user to be vulnerable they'd have to already have the compromised
version downloaded locally and be using an old version of the grimoire that
didn't have the new key/signature.  In this case they probably already have
it installed, so whether or not sorcery can tell if it's bad or not on an
install is sort of a moot point, regardless of the verirication used.  It's
an edge case, but we should still account for it.

This raises the point though that sorcery should be checking a gurus.gpg
revocation list on the first cast of each 24-hour period or something.
Note that doing the same thing with regular hashes would be more difficult,
since we'd basically have to implement the idea of a revocation list in
sorcery ourselves, then publish a list of any known bad hashes for sorcery
to pull.

> The total count is +3 for hashes, +2.5 for signatures. I hereby conclude 
> that
> SMGL maintainer signatures on individual source packages are not in any way
> better than strong hash values, in detecting the integrity violations of 
> said
> packages.

"Not in any way better" is leaving out the consideration around what
sorcery does and doesn't have to know about hashes (and now revocation
lists), which has been stated many times as a primary reason we're
suggesting doing this.  If the current attacks against hashes continue to
proliferate, we have to become hash experts and keep deciding the best one
to use and rehashing everything to keep up.  If we push this out to GPG, we
let them stay the experts and just script resigning things when they change
the algorithms they use.

You've talked previously about being security experts or not wrt
certification.  It is precisely because we know we're not as expert at
crypto as some people are that we don't want to keep responsibilty for the
crypto used and possibly put our users at risk.

And I don't buy your -0.5, it's not that difficult to deal with, and the
other benefits outweigh it.

Attachment: pgpFlreIkmamx.pgp
Description: PGP signature