Public Git hosting

Posted Oct 25, 2011 15:31 UTC (Tue) by bgilbert (subscriber, #4738)
Parent article: KS2011: Kernel.org report

What is the concern regarding sites like github? If the fear is commit tampering, shouldn't it be sufficient to include the tip SHA-1 in the pull request?

And the prohibition against HTTP makes no sense to me at all.

Public Git hosting

Posted Oct 25, 2011 16:31 UTC (Tue) by dlang (guest, #313) [Link]

the issue is that the e-mail requesting the pull can be forged, and since anyone can get a github account, how do you know the pull request is really from the trusted person?

if someone is requesting a pull from a place that is known to have done user verification this isn't an issue.

note that this is not saying that you have to have an account on one of these trusted places to participate in kernel development. it's just the final layer (the lieutenants and maintainers sending their pull requests to Linus) that is has this requirement. This is so that Linus can trust the source he is pulling from, at the lower levels the patches are supposed to be validated more directly so there is less need for trust.

Public Git hosting

Posted Oct 25, 2011 19:38 UTC (Tue) by corbet (editor, #1) [Link] (8 responses)

As dlang said, it's a matter of authentication; how do you know that the repository really belongs to the person named in the pull request?

About http, that's purely a performance thing. The git:// protocol is far more bandwidth-efficient than the git-over-http protocol.

Public Git hosting

Posted Oct 25, 2011 20:13 UTC (Tue) by obrakmann (subscriber, #38108) [Link] (5 responses)

Well, they are setting up this neat GPG web of trust, so why not make use of it? Signing the pull request with said GPG key should be enough to verify the requester's identity, shouldn't it? Sure, at this time, it wouldn't fly yet, but half a year down the road? Or am I missing something?

Public Git hosting

Posted Oct 25, 2011 21:09 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

Linus commented on this by pointing out that the GPG related validation tools are still to cumbersome to use.

Public Git hosting

Posted Oct 26, 2011 0:46 UTC (Wed) by neilbrown (subscriber, #359) [Link] (2 responses)

GPG signing in git is possibly cumbersome, partly because you can only sign a tag, and I don't think we want to be creating tags for every pull request (though it they don't propagate by default that might be OK).

All you really need to sign is the email requesting the 'pull' and make sure the hash of the commit is in that email and easy for Linus to either use directly or check.

Unfortunately I cannot ask Linus to
git pull git://myhost/path hash-tag-goes-here

because git doesn't want a hash-tag, it wants a refspec.

However if git-pull were changed to accept that, and git-request-pull were changed to output exactly the right 'git pull' command, then Linus could just verify the signature on the email (which I hope is email client is up to!) and use the command that is in it. Then it doesn't matter how secure the hosting provider is - if the pull succeeds, it can be trusted as much as the person who signed the email.

So yes: a little bit cumbersome, but not much.

Public Git hosting - pull request in signed email

Posted Oct 28, 2011 20:19 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

All you really need to sign is the email requesting the 'pull' and ...

Isn't that (verifying that email signature) the part Linus says is too cumbersome?

I haven't personally ever known anyone to verify an email signature, and I'm pretty sure my email reader (Emacs Rmail) can't do it, so I don't know what's involved.

Public Git hosting - pull request in signed email

Posted Oct 28, 2011 21:16 UTC (Fri) by neilbrown (subscriber, #359) [Link]

If someone can do DNS spoofing, or break in to my server, then Linus can have no guarantee that what he pulled is what I wanted him to pull. Adding the SHA1 of the commit can give him that guarantee.

The mail reader I use (clawsmail) verifies email signatures quite nicely, and will even fetch keys for me. I don't think it warns me when someone changes keys which is something I would like.

Even emacs/vm can check mail signing...

I assumed that the bits that were too cumbersome were the signing and verification built in to git-tag.

Public Git hosting

Posted Nov 3, 2011 1:06 UTC (Thu) by slashdot (guest, #22014) [Link]

How so?

As far as I can tell, most mail clients support GPG and will tell you whether an e-mail is signed by a trusted key.

If using a custom mail client, it should be very easy to invoke GPG appropriately to do that check.

Public Git hosting

Posted Oct 25, 2011 21:12 UTC (Tue) by jimparis (guest, #38647) [Link] (1 responses)

> About http, that's purely a performance thing. The git:// protocol is far > more bandwidth-efficient than the git-over-http protocol.

Surely the smart HTTP transport is fine?

Public Git hosting

Posted Oct 25, 2011 21:14 UTC (Tue) by corbet (editor, #1) [Link]

Linus did mention the smart protocol and say it was better. Unless the developer says that the server uses smart http, though, it's not evident from the pull request and Linus is likely to ignore it.