Signing snapshots

[Martin Pool]

On 21 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:

> >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? 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
> In my changeset plugin, I don't support working tree yet, as there are
> fields I would like to get from the revision info. But you could just as
> easily do the basic work for commit so that you have an effective
> Revision entry, just one that is not committed to the repository. If you
> don't associate a Revision id with it, then it is just free-floating.

Of course people may choose to do "bzr diff | gpg --clearsign | mail
foo", to send through their uncommitted changes.  On the whole though
I think this is not the best approach: there is no systematic way to
store their comments, and there is no identifier for the thing they
submitted.  Add those two and you basically have a revision.

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

I think the best model to follow here is that of GPG in mail clients
like Thunderbird or Evolution.  When reading a signed revision gpg can
help us detect any of several states:

  no signature
  bad signature
  unknown key (though perhaps try to auto-fetch)
  untrusted key
  trusted key
  trusted key corresponding to the purported author

We can get up to the penultimate step without any code other than gpg
(and maybe gzip) needing to look at the data, and we presume gpg is
safe.  Only once the data is signed by a reasonable key do we unpack
the XML.

In the best case all revisions would be in the final class: you get a
revision from me, know it's from me, and we're good.  In practice
somebody new to a project may not yet trust that my key is really mine
and we need to get a balance between warning them and making it
usable.

> >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? That is a good idea if possible.
> With the multiple-ancestor code going in, it seems we might be pulling
> other people's histories, and I certainly think we should also pull the
> signatures if we have them available.

Yes, I think we can and should do that.

-- 
Martin