Suggestion: generalize signed tags into "assertion objects"

Linus Torvalds wrote:

I'm thinking out loud here, but maybe instead of just "tag objects", how about broadening them into "assertion objects" that include (1) a claim and (2) a signature. Monotone, for example, can do this -- it has a generalized mechanism for signed assertions.

A claim might be that some commit is a tag ("Linus Torvalds says this is tag 2.6.12-rc2") or even "I did this" ("Greg KH really committed this"). You could create the latter objects when you push (just sign the head commit), and that would make it really easy to do checks across an entire repository (who said what?). Currently people can send signed emails that they really DID commit something, but then that data's not available to everyone else. Signed assertions about commits would suddenly make it possible for arbitrary people to detect & counter subverted repositories (if they have the public key list); fsck-cache could check signatures as it went.

With a more generalized assertion mechanism, you could make the same assertion multiple times, e.g., if your key gets captured, you could go back and re-sign with a new key, simply creating a new assertion object. You can also make assertions about multiple objects (e.g., assert some relationship between far-removed commits). I'd expect assertion objects to be stored by their hash, just like any other object.

Yes, that makes sense. I think .git/tags/xxx should point to the assertion objects that claim they are tags; you can then check if you accept the assertion object's signature when you try to use it (and locally cache that acceptance once you've checked the signature).

For generalized assertion objects, you need a way to travel FROM the object(s) being described TO the assertion object. A simple method might be to create subdirectories with the name derived from the object(s) being described, and inside the subdirectory have a set of files that have the hashes of the assertion objects. E.G., this kind of structure

  00/
    10f32aca7ba78e2cd95dcfedee0e6329edb735      (commit object)
    10f32aca7ba78e2cd95dcfedee0e6329edb735.d/
      1038e8b8e04b287ec876594cbab9df4af09ce131 ->
                        ../../1038e8b8e04b287ec876594cbab9df4af09ce131
  10/
    38e8b8e04b287ec876594cbab9df4af09ce131     (assertion object)

There's no reason you can't point to assertions from multiple places, which would make them cheap to find when needed.

One problem with symlinks is that some dopey filesystems don't support them :-(. In this case, though, if they got copied multiple times they'd just waste space & not interfere with meaning, since they'd all be static read-only. An alternative would be 0-length files whose names are the hashes.

...

--- David A. Wheeler