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

RE: Signinig a commit with multiple signatures

From
Jason Pyeron <jpyeron@pdinc.us>
Date
Aug 19, 2014, 13:09 UTC
Message-ID
<FC21F8BBC6EF41E1952CA340138A50D2@black>
In-Reply-To
<20140819080510.GC7712@peff.net>
Show 17 quoted lines
> -----Original Message-----
> From: Jeff King
> Sent: Tuesday, August 19, 2014 4:05
> 
> On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote:
> 
> > I am working on an open source project right now where we 
> are looking
> > to enforce a N of M audit approval process. It turns out that git
> > supports verifying multiple signatures because gpg supports 
> signature
> > merging.
> 
> In the scheme you propose, the commit object is actually rewritten. So
> whoever made and signed it first will then need to rebase on 
> top of the
> rewritten multi-signed version.
Not exactly. A known and shared commit is used as the parent of an empty, no changes commit. The "no changes" commit object is taken and passed around before being added into the repository. There is no need for a rebase.
But my scheme uses out-of-band process to accomplish this. The idea of using git to "distribute" the conflict resolution seemed like a valid use case of sharing a working copy state for a distributed commit, just like this. [1][2]
> 
> Is there a reason not to use detached signatures, and let each person
Yes. The embeded signatures provides the best user experience (UX) for verification.
Show 21 quoted lines
> add them after the fact? You can store them in git-notes and then push
> them along with the other commits (you can even check in a pre-receive
> hook that the commits meet your N of M criteria, as long as everybody
> has pushed up their signature notes).
> 
> > $ cat write-commit.ruby
> > #!/usr/bin/irb
> > require 'fileutils'
> > file = File.open(ARGV[0], "rb")
> > content = file.read
> > header = "commit #{content.length}\0"
> > store = header + content
> > require 'digest/sha1'
> > sha1 = Digest::SHA1.hexdigest(store)
> > require 'zlib'
> > zlib_content = Zlib::Deflate.deflate(store)
> > path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
> > FileUtils.mkdir_p(File.dirname(path))
> > File.open(path, 'w') { |f| f.write zlib_content }
> 
> I think this is just "git hash-object -w -t commit <file>", isn't it?
Let me find the most complicated way of saying this, yes. I feel silly for that.
-Jason

[1]: http://git.661346.n2.nabble.com/Sharing-a-massive-distributed-merge-td6178696.html [2]: http://git.661346.n2.nabble.com/Sharing-merge-conflict-resolution-between-multiple-developers-td7616700.html

Previous: Jeff KingNext: Christian Couder
Message 9 of 10 in “Sharing merge conflict resolution between multiple developers”
  1. Chris PackhamAug 11, 2014
  2. Junio C HamanoAug 11, 2014
  3. Chris PackhamAug 11, 2014
  4. Junio C HamanoAug 12, 2014
  5. Nico WilliamsAug 11, 2014
  6. Jeff KingAug 17, 2014
  7. Signinig a commit with multiple signaturesJason Pyeron, Aug 17, 2014
  8. Jeff KingAug 19, 2014
  9. Jason PyeronAug 19, 2014
  10. Christian CouderAug 11, 2014

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.