Signing snapshots

[Aaron Bentley]

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

John A Meinel wrote:
> However, in the end, it comes down to signing a bunch of bytes. And at
> least the last proposal I read was to sign the bytes that make up the
> revision file. Which means that modifying that at all means you need to
> re-sign.

So this is an alternative proposal; a proposal to be more selective
about what we sign.  Nothing's set in stone yet.

>> 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.
> 
> 
> But what happens if *I* upgrade to sha-160, but I'm branching off of
> *you* and you haven't upgraded. I can't re-sign your signatures, I still
> have to trust sha1 for the first 600 revisions.

If you branch off me, you can sign it.  Anyone accessing your branch can
trust you, and of course you can trust yourself.  If someone later tries
to retrieve my copy, they can find out whether my signatures are also
valid for the data they downloaded.

And if there was no predecessor signature embedded in the revision, you
could be selective about what you signed, and only sign your own stuff
instead.  That would prevent people from downloading untrusted old
revisions, which is probably to the good.

>> 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.
> 
> 
> Sure, but only if you are the owner.

I'm not sure it's necessary to require the signature of the committer.
The signature of the branch owner may be enough.

> And that doesn't change the
> signatures in the 500+ copies of your tree that someone else already
> copied.

So as long as we ensure that adding a new hash doesn't break existing
signatures, we're in good shape, right?

> I don't think there is any way to get around needing to try and
> understand the data they sent, in order to make sure it is valid. You
> could restrict what keys you are willing to look more closely, though.
> So you check the signature, make sure it is valid, *and* that you trust
> it enough to read the revision contents to make sure that the
> committer="" tag matches the gpg key.

I think I'd rather assign trust by branch location than by committer.
Say I'm on your keyring, I set up a bzr.dev mirror that you use, and
then I make a malicious commit.

>> 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.
> 
> 
> The current method, is to sign the revision-store file, with the idea
> being that if you started at the beginning, you could validate the
> revfile. Validating a full-text is easy, then you patch it, and can
> validate that against the next inventory sha, which is validated from
> the revision entry.

Yes, validating the full text is easy, but by then, you're already
knee-deep in untrusted data.

> Sure. You can do this with custom keyrings. So that you say "trust
> things on this branch using this keyring."

Okay, but I don't want to become a GPG expert, and if bzr can make it
easier, I'm all in favour of that.

> I'm not really sure how to specify what keys can commit to what
> branches. Are you thinking to add something into the .bzr/ directory
> such as "x-allowed-keys"?

That's the kind of thing I mean, only it would control what keys could
*sign* revisions, not commit them.

> Is it something that is controlled at the repository level, and/or is
> versioned? Or is it something that each person drops into their local
> branch?

I was thinking of a local-only file.

> Is the "StreamTree" class free from bugs, such that you
> can't exploit the remote conversation to cause the local bzr to do bad
> things.

I'd say it's a pretty simple interface.  It has a much better chance of
being bug-free than say, the RemoteBranch code, the merge code :-( or a
ChangesetTree.

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

iD8DBQFCuGJq0F+nu1YWqI0RAkgPAJwLfaKLNmDwvDZHjsD7IkfbeZqDfACeM/nO
Iv3gTYoQlRYEi/KxLP9/4Xc=
=EoNa
-----END PGP SIGNATURE-----