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

From: Ted Ts'o <tytso@mit.edu>
Date: Oct 31, 2011, 20:30 UTC
Message-ID: <20111031203059.GJ16825@thunk.org>
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>

(removing linux-ide and linux-kernel)

On Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> 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