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

[Ted Ts'o <tytso@mit.edu>]

(removing linux-ide and linux-kernel)

On Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:
> 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.

I wouldn't put it as "we don't trust Linus's tree", because it's not
true.  In general, we do trust Linus's tree.  On the other hand, it's
useful if the proof which was submitted at the time of the push could
be verified by third parties.

Suppose the project wasn't Linus, but some other project, say, a
hypothetical Desktop system called Troll3.  Let's assume that it's run
by a sole dictator, S. Crew Powerusers, who blindly assumes that any
tree on github is secure, and is confident he or she can detect social
engineering attacks caused by a bad guy grabbing a developer's SSH key
used to push to github, and who can fake a pull request to Linus that
looks real but is really originated by the bad guy.  Let's assume
further that the pull request has a signed tag which could be used to
detect such forgeries, but because Mr. Powerusers can't be bothered to
check the tag, because he can't figure out how to update his GPG
keyring and besides, he hates crypto stuff --- and the bad guys know
this, and are good (Kevin Mitnick or better) at social engineering
attacks.

In this sort of scenario, it's useful if *other* people could
independently verify the Troll3 git tree via the crypto signatures,
even though the central maintainer couldn't be bothered to check the
crypto signatures.


Here's an idea.... what if the "signed push" information could be
embedded into the merge commit's description?  That is, the
information could sent via a signed git tag, or some other mechanism,
but then part of the git merge would incorporate the GPG signature
into the merge commit's description field (and we could always create
a merge commit so there's a place to put the digital siganture).  That
way, it's mostly out of the way, but it's in a well-defined place
where it will always easy to have a third party independently verify
the source of a set of commits in the git tree.

The problem with notes and tags is that they have to be pushed
separately, and might get lost; where as if they are stored in the
merge commit's description, they will always be there.

							- Ted