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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 1, 2011, 21:21 UTC
Message-ID: <CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com>
In-Reply-To: <7vwrbjlj5r.fsf@alter.siamese.dyndns.org>

On Tue, Nov 1, 2011 at 12:47 PM, Junio C Hamano <gitster@pobox.com> wrote:

>
> While I like the "an ephemeral tag is used only for hop-to-hop
> communication to carry information to be recorded in the resulting
> history" approach, I see a few downsides.

So I do agree.

I'd actually be *happier* with a generic multi-line "branch description" thing that involves no git objects at all, just a nice description of what the branch is.

The fact that you could also hide a signed version of the top-of-branch there would be kind of a side effect, and wouldn't be a requirement.

I hate how anonymous our branches are. Sure, we can use good names for them, but it was a mistake to think we should describe the repository (for gitweb), rather than the branch.

Ok, "hate" is a strong word. I don't "hate" it. I don't even think it's a major design issue. But I do think that it would have been nicer if we had had some branch description model.

The only reason I suggest a tag is really because it would fit with existing tooling - especially the git transport protocol. So it's not that I actually think that a tag is the right way to describe (and sign) the branch, it's just that it's the way that wouldn't require any changes other than in "git push -s" and "git pull".

Show 8 quoted lines

>  * To verify the commit C that was taken from the tip of lieutenant's tree
>   some time ago, one has to find the merge commit that has C as a parent,
>   and look at the merge commit.  For example "git log --show-signature"
>   would either show or not show the authenticity of C depending on where
>   the traversal comes from. You certainly can implement it that way, but
>   "some child describes an aspect of its parent, but not necessarily all
>   children do so" feels philosophically less correct than "the commit has
>   data to describe itself".

Yeah.

Having thought about it, I'm also not convinced I really want to pollute the "git log" output with information that realistically almost nobody cares about. The primary use is just for the person who pulls things to verify it, after that the information is largely stale and almost certain to never be interesting to anybody ever again. It's *theoretically* useful if somebody wants to go back and re-verify, but at the same time that really isn't expected to be the common case.

So I'm wondering if we want to save it at all. it's quite possible that realistically speaking "google the mailing list archives" is the *right* way to look up the signature if it is ever needed later.

Maybe just verifying the email message (with the suggested kind of change to "git request-pull") is actually the right approach. And what I should do is to just wrap my "git pull" in some script that I can just cut-and-paste the gpg-signed thing into, and which just does the "gpg --verify" on it, and then does the "git pull" after that.

Because in many ways, "git request-pull" is when you do want to sign stuff. A developer might well want to push out his stuff for some random internal testing (linux-next, for example), and then only later decide "Ok, it was all good, now I want to make it 'official' and ask Linus to pull it", and sign it at *that* time, rather than when actually pushing it out.

And I suspect signing the pull request fits better into peoples existing workflow anyway - sending out the email to ask the maintainer to pull really is the "special event", rather than pushing out the code itself.

                      Linus