On 1/16/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
On Monday 2007, January 15 18:36, Martin Langhoff wrote: > > * Vandal spends one year developing reasonable relationship with Idiot, > > all patches are good. Occasional big patches are pulled by Idiot. > > If you are using signatures, the trojan horse would make sure he gets > his patches signed. What is the advantage again? He can't sign it as someone else, and so when it is eventually discovered the culprit can be hunted down and flogged.
Fair enough. But you should should not pull from peripheral devs. Ever. Core developers pull from eachother, everyone else posts patches. That's how it's meant to be used. And if you do a pull from a peripheral developer (to grab a specific interesting patch series), you review it to check it contains what you expect. As the person doing the merge, _your_ name is on the line.
> IIRC Linus discussed this early on, and his view was that authorship > only gives you false security. The only security is in reviewing code. > And that the code-signed patches are dog-slow too. Eh? It's only a little bit of extra text to carry around. It's signed by the original author when it enters a repository, so it's not a huge price to pay in any one place. The checking, if you wanted to enable it, would only be done once per incoming commit to a master repository. All-in-all, nothing that you wouldn't be willing to pay if you wanted this feature.
I guess the argument was against the cost of running expensive checks in operations that should be fast. On the other hand, if youare happy for the git internal machinery to ignore alll this, you _could_ add this trivially with a slight modification of the commit msg. At commit-time, just add a signature block at the bottom, making sure you are including the tree and parent SHA1s in the text signed by the commit (the commit however will have no GPG starts here" line at the top when it is displayed).
As an aside; I would also suggest that this isn't just about people trojaning a commit. You could also argue that without it, this whole Signed-Off-By business is a bit a moot point.
Well, it's covered by a trust-but-review ethos...
The signed-off-by lines in the kernel are being used to establish original authorship and entry path of every line in the kernel. It's fairly worthless though when the "signing" is just someone writing an easily forged line of text. For example, what is to stop that naughty lad Linus from adding some code the infringes a copyright to the kernel and adding a "Signed-Off-By: Martin Langhoff" to the bottom? Equally, when SCO come knocking with their "we wrote that line", a secure digital signature chain would go a long way to proving that a submission wasn't faked.
Oh, evil Linus. It takes a bit more work to take my name in vain. SMTP hosts, IP addresses of the sending machine, etc. And yet... <social, nontechnical commentary follows> ... you probably know about Debian and its keysigning parties. One of the net results is that pretty much nobody reviews the work developers do in their packages. Nobody. All signed and pretty, but in most debian packages the review is nil. And you can mostly trust that a given upload came from me or someone that has my keys. Sure. But trust has smothered review. So while I don't disagree that it can be implemented easily, I doubt it will improve the technical quality of a project to introduce it. And it is trivial to prove that it lowers the social/human quality, as it brings in all sorts of politics and exclusion games (present in CVS/SVN today). Starting from the "are you in the keychain?" game, to forcing passport-based keysigning parties (not bad in itself) that lead to bs like "I don't trust non-western-central-country-passports", "I don't think you look like your passport picture". And then smart people get tired and do stuff like this http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning Sorry about the rant :-) but I consider this kind of stuff a good reason to stay away from a project. Judge the patch, nothing else. martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html