Re: Signinig a commit with multiple signatures
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.
Is there a reason not to use detached signatures, and let each person
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?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Signinig a commit with multiple signatures
-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.
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signinig a commit with multiple signatures
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.
My question is how can this workflow best be added into git and if not added
atleast supported.
Here are the manual procedures (scripts are in the bundle too):
Procedures:
1. Identify a normal commit.
2. create a new commit file as:
parent commit-id-of-step-1
tree tree-id-from-git-cat-file-commit-commit-id-of-step-1
author CipherShed Security Team secur...@ciphershed.org
timestamp timezone
committer Actual Person usern...@ciphershed.org timestamp timezone
gpgsig output-from-merge-sig-tool [1]
more-output
more-output
Comments for this commit
...
...
3. run ruby script [2] to add commit to git db
4. git update-ref refs/heads/BRANCH-NAME new-commit-id
To do this most properly I feel like there needs to be a way to share the
repository state and intterrupt the commit process.
Comments?
1:
$ cat merge-multisigs.sh
#!/bin/bash
(
for i in $@
do
gpg --dearmor $i
done
) | gpg --enarmor
2:
$ 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 }
P.S. This was inspired by actual events and the parent thread.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
multisign.bundle
Description: Binary data
