git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Commit signing

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Jan 15, 2007, 22:26 UTC
Message-ID
<46a038f90701151426t7f25b50cl21a65c9b283829ef@mail.gmail.com>
In-Reply-To
<200701151923.07493.andyparkins@gmail.com>
On 1/16/07, Andy Parkins <andyparkins@gmail.com> wrote:
Show 10 quoted lines
> 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.

Show 9 quoted lines
> > 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...
Show 8 quoted lines
> 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
Previous: Andy ParkinsNext: Johannes Schindelin
Message 18 of 21 in “Commit signing”
  1. Andy ParkinsJan 15, 2007
  2. Matthias KestenholzJan 15, 2007
  3. Shawn O. PearceJan 15, 2007
  4. Shawn O. PearceJan 15, 2007
  5. Johannes SchindelinJan 15, 2007
  6. Daniel BarkalowJan 15, 2007
  7. Johannes SchindelinJan 15, 2007
  8. Shawn O. PearceJan 15, 2007
  9. Karl HasselströmJan 15, 2007
  10. Andy ParkinsJan 15, 2007
  11. Shawn O. PearceJan 15, 2007
  12. Johannes SchindelinJan 15, 2007
  13. Andy ParkinsJan 15, 2007
  14. Johannes SchindelinJan 15, 2007
  15. Andy ParkinsJan 15, 2007
  16. Martin LanghoffJan 15, 2007
  17. Andy ParkinsJan 15, 2007
  18. Martin LanghoffJan 15, 2007
  19. Johannes SchindelinJan 15, 2007
  20. Jakub NarebskiJan 15, 2007
  21. Jeff KingJan 15, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.