Re: [git patches] libata updates, GPG signed (but see admin notes)

Linus Torvalds <torvalds@linux-foundation.org> writes:

You have misread me this time.

I think the minimalistic "paste this line to your 'git pull' command line and expect to get history leading to this commit" like you did in your patch would be the solution that is the least painful and still useful, which is an important criterion for wide adoption.

I however have a small trouble with "lieutenants use signed tags in order to prove who they are to Linus", depending on the details.

It certainly lets you run "git tag --verify" after you pulled and will give you assurance that you pulled the right thing from the right person, but what do you plan to do to the tag from your lieutenants after you fetched and verified? I count 379 merges by you between 3.0 (2011-07-21) and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on average. Will these tags be pushed out to your public history?

On one hand, we (not just you but the consumers of "Linus kernel") can consider these tags are of ephemeral nature. Once they are used for _you_ to verify the authenticity, they are not needed anymore. The consumers of "Linus kernel" by definition trusts what you publish, so as long as they have a way to verify the tip commit you push out, they _should_ be happy. If you take this stance, you would not push these tags out so that you do not have to contaminate the tags namespace with them, and you might even choose to discard them once you pulled and verified the lieutenants' tips to avoid contamination of your own refs namespace.

On the other hand, the consumers of "Linus kernel" may want to say that they trust your tree and your tags because they can verify them with your GPG signature, but also they can independently verify the lieutenants' trees you pulled from are genuine. Keeping signed tags and publishing them is one way to make it possible, but 400 extra tags in 3 months feels like an approach with too much downside (i.e. noise) for that benefit.

On Git mailing list, we have been toying with a couple of ideas. The simplest one (cooking in next) is to allow committers to add gpg signature in an additional header of the commit objects. "git show" and friends are taught how to verify these signatures when asked.

This might have a potential downside on the lieutenants' workflow; after integrating the work by their sub-lieutenants and by themselves, they would test and review the result to convince themselves that it is worth asking you to pull, and then they have to either

    (1) "commit --amend --gpg-signature" the tip; or

    (2) "commit --allow-empty --gpg-signature" to add an empty commit
        whose sole purpose is to hold the signature (and avoid amending
        the tip)

before pushing it out, asking you to pull.

An alternative we have discussed was to store gpg signature for the commit ("push certificate") somewhere in notes tree and push that out, certifying that the commit indeed came from the pusher, but that would:

 (1) require upstreams to fetch (and possibly suffer from merge conflicts
     in notes tree) push certificate whenever they pull from their
     lieutenants; and

 (2) require downstreams to also fetch the notes tree for "push
     certificates" (especially when the central repository is shared among
     multiple people) before adding their own signature and then push it
     back (and possiblly suffer from "non-fast-forward" in notes tree).

both of which are downsides coming from "notes" being not a very good match for what these signatures are trying to achieve.

Namely, the current "notes" mechanism is designed to keep track of history of changes made to notes attached to commits, but for the signature application, we do not care about the order that signatures came to two separate commits. "Non-fast-forward" conflicts while pushing, or having to fetch and merge before adding one's own signature, are unwanted burden imposed only by choosing to use "notes" for storing and conveying the signature.

Also the "notes" approach would end up mixing "push certificates" for different branches (this won't be an issue in your repository where there is only one branch) into a single "notes" tree. We would want to use something that behaves more like the "auto-following" semantics of tag objects. You would want to fetch only signatures that are attached to the commits you are fetching. Use of signed tags, or commit objects that can be signed in-place, have this property, but storing signature in notes tree does not give it to us.

I think further discussions on this should continue on the git mailing list.