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. > 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. 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. 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. I'm not sure how far commit signing would go towards preventing that, but it could certainly be part of the solution. Commit signing doesn't have to be all about trusting developers, it can be about recording history in an independently checkable way. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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