Question

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 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.

Answer 1

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.