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

On Wed, Nov 2, 2011 at 6:19 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Btw, having now done odd things with signed tags (because we've used them as a side-band verification mechanism), I can certainly also say that the signed tags have their set of problems too.

So signed tags aren't perfect. They were designed for making releases, and that shows very clearly in how git works with them. The default choices that git makes are very awkward indeed when you use signed tags as "security tokens".

But unlike the "sign the commit" approach, those are implementation and UI issues, not "fundamentally broken design" issues.

For example, fetching a single signed tag with git is surprisingly hard. It *shouldn't* be hard - and there's no underlying technical or design reason why it would be hard, but it is. Why? Because all the git actions when it comes to tags are all geared towards one particular use, that is *not* about the signature checking aspect of them.

Here's an example: Rusty Russell now makes nice signed tags for the things he asks me to pull, and then states them in the pull message. So he will mention that he has a tag named

   rusty@rustcorp.com.au-v3.1-8068-g5087a50

in his git repository at

   git://github.com/rustyrussell/linux.git

and while I don't think his tag names are all that wonderful, it makes sense from an automated script kind of standpoint.

Now, let's try to get that tag:

  [torvalds@i5 linux]$ git fetch
git://github.com/rustyrussell/linux.git
rusty@rustcorp.com.au-v3.1-8068-g5087a50
  fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50

oops. Ok, so his tag naming is *really* akward. Whatever. Let's try again:

   [torvalds@i5 linux]$ git fetch
git://github.com/rustyrussell/linux.git
refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50
   From git://github.com/rustyrussell/linux
    * tag
rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> FETCH_HEAD

Ahh, success!

Oops. Nope. It turns out that git will *peel* the tag when you fetch it, so FETCH_HEAD actually doesn't contain the tag object at all, but the commit object that the tag pointed to. MAJOR FAIL.

Quite frankly, I think that's a git bug, but it's a git bug because "git fetch" was designed to get the commit to merge. Fair enough. Let's work around it, and rename the tag at the same time:

   [torvalds@i5 linux]$ git fetch
git://github.com/rustyrussell/linux.git
refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50:refs/tags/rusty
   From git://github.com/rustyrussell/linux
    * [new tag]
rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> rusty
    * [new tag]
rusty@rustcorp.com.au-v3.1-2-gb1e4d20 ->
rusty@rustcorp.com.au-v3.1-2-gb1e4d20
    * [new tag]
rusty@rustcorp.com.au-v3.1-4896-g0acf000 ->
rusty@rustcorp.com.au-v3.1-4896-g0acf000
    * [new tag]
rusty@rustcorp.com.au-v3.1-8068-g5087a50 ->
rusty@rustcorp.com.au-v3.1-8068-g5087a50

WTF? Now we finally *did* get the tag, and we can do

   git verify-tag rusty

and that will work. But what the hell happened? We got three other tags too that we didn't even ask for!

So we have actual git bugs here, that relate to the fact that we've treated signed tags specially, and have magic code to basically say "if there's a signed tag that is reachable from the thing you pull, and you're not just doing a temporary pull into FETCH_HEAD, we'll fetch that signed tag too".

Again - not a fundamental design mistake in the data structures, and it actually made sense from a "signed tags are important release points" standpoint, but it makes it *really* inconvenient to use signed tags for signature verification.

Also, the fact that the signed tag gets peeled when we do fetch into FETCH_HEAD also means that we can't actually save the signature in resulting the merge commit. The merge, instead of being able to perhaps save the information that we merged a nice trusted signed point, only has the commit.

But practically, all of these issues should be pretty easily solvable. So it should be quite easy to make

    git pull <repo> <tag-name>

just do the right thing - including verifying the tag, and adding the information in the tag into the merge commit message.

So signed tags are not mis-designed from a conceptual standpoint - they just work really really awkwardly right now for what the kernel would like to do with them.

With a few UI fixes, I think the signed tag thing would "just work".

That said, I do think that the "signature in the pull request" should also "just work", and I'm not entirely sure which one is better. It might be more convenient to get the signature data from the pull request. So I'm not at all married the the notion of using signed tags for this.

                       Linus