How commits are signed in git. Utilizes git notes support. Status unclear.
Why do we care about that?
Seems there is solluttion for gpg signing http://weierophinney.net/matthew/archives/236-GPG-signing-Git-Commits.html
http://permalink.gmane.org/gmane.linux.gentoo.scm-migration/48
Should become a non-issue before long: http://permalink.gmane.org/gmane.linux.gentoo.scm-migration/111
Robert is retiring, not sure who will take care of this now :/
https://github.com/gitster/git/blob/master/Documentation/RelNotes/1.7.9.txt from 1.7.9_rc1 tag: Git v1.7.9 Release Notes (draft) ======================== Updates since v1.7.8 -------------------- [...] * "git commit" learned "-S" to GPG-sign the commit; this can be shown with the "--show-signature" option to "git log". [...]
Current git 1.7.9_rc1 has commit signing and signature checking ability From Reflog * "git log" learned "--show-signature" option to show the signed tag that was merged that is embedded in the merge commit. It also can show the signature made on the commit with "git commit -S". * "git commit" learned "-S" to GPG-sign the commit; this can be shown with the "--show-signature" option to "git log".
I've added initial support to repoman here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6cbf430ed3db0e9128a29280ca08f0309cbd933d In order to sign commits with git, you will need Git >=1.7.9 and your key will have to be configured by `git config user.signingkey key_id`. Also, the repository will need to have "sign-commits = true" in metadata/layout.conf. It seems that the commit signing features are undocumented in git-manpages-1.7.9, so we have to use git's source code for documentation: git commit -S, --gpg-sign[=key_id]: builtin/commit.c: { OPTION_STRING, 'S', "gpg-sign", &sign_commit, "key id", git log --show-signature: revision.c: } else if (!strcmp(arg, "--show-signature")) {
(In reply to comment #8) > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6cbf430ed3db0e9128a29280ca08f0309cbd933d I've done a fixup to the above commit, so if you want to test, use this instead: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d6850f3ac839326c5596db5a570bc7832bb394e
(In reply to comment #9) > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d6850f3ac839326c5596db5a570bc7832bb394e This is released in portage-2.1.10.45 and 2.2.0_alpha85.
So this seems more or less done, or are there missing pieces?
Do we have any code to verify the signatures?
(In reply to comment #12) > Do we have any code to verify the signatures? I don't know, but if anybody has code to verify Manifest signatures, then that would be a good starting point for getting a set of valid keys.
Well git does signature verification by itself git log --show-signature =D
(In reply to comment #14) From http://mikegerwitz.com/docs/git-horror-story.html#_enforcing_trust : See the part about ... git log --pretty="format:%H %aN %s %G?" ... and the gpg web of trust
who can stick a fork this this? it looks like it's resolved.
(In reply to comment #16) > who can stick a fork this this? it looks like it's resolved. Portage validation at the sync'ing level is still missing; it just has write support, basically.
Portage does not validate commits *now* anyways. `emerge-webrsync` snapshots are signed individually anyways. I have filed bug 463510 to track implementation of signature verification.
(In reply to comment #17) > (In reply to comment #16) > > who can stick a fork this this? it looks like it's resolved. > > Portage validation at the sync'ing level is still missing; it just has write > support, basically. This sounds like it would be pretty hard to implement - the head of the tree will most likely never be signed. Typical workflow - sign a commit, then git pull/rebase (which is not signed), and then git push. The head points to an unsigned commit. Even if you use merge commits I don't believe you can sign them. So, the only way that head will point to a signed commit is if the tree is rebased immediately before a change is committed to it and then pushed. That seems unlikely, especially with testing. So, to verify a signature we would need to verify that the commit where content was actually introduced was signed. I really think this should be closed - I'm all for improving things, but it isn't like we're getting any signature verification benefits by hanging onto cvs.
OK I'm putting my head on the block here, this item is resolved as good as it will ever git. (Tree validation in portage is another issue and should be discussed in a separate bug. It is not done now, and should not block the migration.)
