Trusted development path in git with signatures

I'd like to build a trusted path for software development. This means that every change in to code must be signed by the author and one reviewer, before being accepted. These signatures for the changes must be verifiable at release time, or there must be some other means of making sure the repository can not have been tampered, or additional changes added.

The version control system that I am expecting to use for this is git, but other options are also accepted. Signing can be via GnuPG or SSL certificates.

The workflow I am thinking would be roughly:

1. Current verified trunk is branched
2. Changes are developed in the branch by one or more developers
3. One or more developers sign the changes made by the branch
4. A reviewer reviews and tests the changes
5. Reviewer signs the changes made by the branch
6. Branch is "merged" in to current verified trunk

Merging does not have to开发者_如何学Python be foolproof such as that unreviewed changes would need to be unmergeable to trunk - just that before a release, there needs to be a way to check if there are any unreviewed (unsigned) changes in trunk. And in general, tampering need not be prevented, only detected.

I'd like a short guide on how to set this up and how each operation is done. Once I get some pointers, I can figure out the specifics myself.

Also, I already know about 'git tag -s' technically, but I am unsure how to apply it to this particular problem.

The changes will not be signed until you tag. Anything before that point can be verified by the author or by another out-of-band mechanism, but not from within git.

git can verify that a change's heritage is correct, but only the signed tag can verify the change itself is correct.

For your workflow, you may just find yourself tagging a lot.

You can sign your tag with your GPG key with -s option in tag git tag -s v0.1.0:

-s

   Make a GPG-signed tag, using the default e-mail address's key

But you can't signed a commit.

Git is a good candidate since:

• each commits are already signed
• the SHA1 key for each commit is enough to be sure the all repo has not been modified
• git tag -s can be used to sign a commit someone didn't make (git tag -m is more explicit)

So:

1. Current verified trunk is branched

   git checkout -b tag_for_last_verified_trunk_content test # branch test

2. Changes are developed in the branch by one or more developers

   [work...] git commit -s -m "dev1 comment" ...

3. One or more developers sign the changes made by the branch

   Already done with their commits, by adding a Signed-of line at the end of the commit message: see this page for explanation on the signed-off process.

   Signed-off-by: user name 

4. A reviewer reviews and tests the changes

    git tag -m "testing" testing # refer to current commit, 
                                   allowing dev to go on with further changes

5. Reviewer signs the changes made by the branch

   git tag -m "tested" tested testing # put a tag on the same SHA1 than 
                                        the "testing" tag

6. Branch is "merged" in to current verified trunk

   git checkout trunk & git merge tested

Cyryl Plotnicki-Chudyk mentions in the comments that, since git 1.7.9 (January 2012, almost 2 years after this answer), you can GPG-sign any commit you want, using git commit -S.
(See commit ba3c69a9, refined more recently in commit df45cb3)