Signing snapshots

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Aaron Bentley wrote:
> 
>>This means that
>> creating a sha-160 signature for a revision requires adding sha-160s to
>> every ancestor revision.  I think this makes merge horizons impossible.
>>
> As soon as you modify the text, you invalidate the signature. Since we
> might actually be signing the gzipped form, you need the actual bytes,
> not something that is newly generated (because you might use a slightly
> different compression level, or the algorithm has been tweaked between
> versions).

My understanding is that we're signing the tree and revision state, not
the storage of the tree or revision.  The point of signing is so that
you can verify that a given revision is or is not a true copy of
revision $foo.  That way, it doesn't matter how a given revision was
produced, and you can produce it whatever way is most effective for the
context.

> For new revisions you can switch from using "revision_sha1" to
> "revision_sha160". You still validate older revisions using sha1
> *because you have to* that is what was signed.

I think that's not great, because it allows someone to stuff bogus
recent revisions into a branch, and get away with it.  I think designing
for re-signing is better.

> Your new 160 hash does not have a sha1 signature.
> 
> You don't have to update the old revisions if you don't want to, in
> fact, once we start doing signatures, updating old revisions would
> require all new signatures.

When you use SHA-160 to produce a signature on an SHA-1 hash, you've got
SHA-1-level security.  It's certainly possible to rewrite a revision and
add an SHA-160 signature.

>> Also, I think signing snapshots makes sense because not every snapshot
>> is a revision.  (Or is it?)  Requiring people to commit in order to
>> produce changesets seems onerous.
> 
> 
> What are you considering to be a snapshot?

I mean the state of all versioned files in the tree.

> Are you thinking that a
> changeset can be produced by comparing to the local working tree? I
> agree with that, but I don't think it needs a permanantly assigned
> signature, if it doesn't have a permanantly assigned revision id.
> If you are wanting to send it as an email, just sign the changeset as it
> goes into the email. bzr diff | gpg --clearsign

It's a nice and convenient way of verifying that the changeset came from
a trusted source, though.  I think unified handling would be good here,
instead of requiring external validation.

But it would be possible to create a temporary revision before sending
the changeset, I guess.


> In my changeset plugin, I don't support working tree yet, as there are
> fields I would like to get from the revision info.

Oh.  Err, what kind of fields?

>> >On the other hand this approach flakes out of the more
>> >important problem of evaluating whether the code is signed by a
>> >meaningful key.
>>
>>
>> Sorry, didn't parse that.
> 
> 
> The idea with a detached signature is that you don't actually have to
> parse a semantic meaning to the bytes. Just read in some bytes and
> compute the sha hash, then check the signature. If you have a
> --clearsign style signature, you have to at least read the file and look
> for where the ---BEGIN and ---END lines exist.

What I don't parse is "this approach flakes out of the more important
problem of evaluating whether the code is signed by a meaningful key".
It sounds like he's talking about *not* signing the hash, to me.

>> I wonder whether there's a useful difference between trusted and
>> authoritative?  E.g., I will trust John Meinel's signature to prove that
>> data is not malicious, but I will only trust your signature to prove
>> that the revision produced is actually
>> mbp at sourcefrog.net-20050620052204-c4253c3feb664088.
> 
> 
> gpg makes the difference between an "UNTRUSTED GOOD" signature, trusted
> good and bad. Which means that if you set your gpg keyring to trust me,
> you will get trusted good on my signatures, if you leave out mpool, then
> you will get untrusted good on his signatures.
> Are you asking for more than this?

Yes, I'm considering the possibility of two layers of signing and two
levels of trust.  One signature on the binary output format, to prove
that the data is not malicious, and one signature on the revision/tree,
to prove that the output is a true copy of a given revision.

That way, you can make a revfile version of the bzr codebase, and I can
trust that revfile version.

Note however, that since we don't want to download the entire revfile,
we can't quickly validate them against a signature, and worse, their
hash will change with every commit.  I guess we'll have to sign the
logical chunks contained within revfiles.

> It is arguable that the trust levels should be built into bzr rather
> than using gpg-keyrings (I know that was a complaint against baz's trust
> model). But gpg has done all of the hard work of implementing trust
> networks, why not use it?

The issue is that I would like to be able to associate a given branch
with a given key, and not accept anyone else's signature on that branch,
even if they are trusted.

>> I'd suggest that we retain that authentication data as well, so that we
>> can determine later that data is signed by a compromised key.
>>
> Retain it in what form? Are you saying that when I pull your patch, I
> should retain your signature?

Yes, that was the idea.

> Interesting idea. I'm wondering if the effort to do a proper chrooted
> bzr would be better spent on just validating user input properly.

It seems to me that chrooting is the more paranoid option.  If you focus
on validating data, you're saying: "This code has few bugs, but if they
are exploited, you can get in trouble".  The chroot approach says "This
code may or may not have bugs, but the chance for damage if they are
exploited is minimal".

Of course, the importance of being able to say the second is a value
judgement.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCuEnt0F+nu1YWqI0RAoSWAJ4wFER1nX6NeOQnwZmXBXK6l3xR8gCfWiZ0
ZbXf1QFF2vlmSKvfcm915+I=
=3EeI
-----END PGP SIGNATURE-----