Support GPG signing review metadata.

[ojarjur]

It would be a big improvement if we provided a way of authenticating review metadata (i.e. git-notes).

To do that, I think we should try to imitate the model git uses for GPG signing commits.

This would mean adding a -S flag to all of the git appraise subcommands that generate review metadata (e.g. review requests, comments, etc). That metadata would then be signed prior to being written. We would use the user's GPG key defined in the user.signingkey config setting to generate this signature. Additionally, the generated git-notes commits would be signed with that same key.

When displaying reviews/comments/etc, we would include information about whether or not the metadata was signed and whether or not the signature could be verified.

We would also want to add a --verify-signatures flag to the git appraise pull command which would cause the merge to fail if any of the incoming git-notes commits or review metadata were not verifiably signed. This would correspond to the same, existing flag in the git merge command. The git appraise pull command should also take a -S flag to cause the git-notes merge commit to be signed. If the --verify-signatures flag is provided then the -S flag should be implied.

To sign a metadata entry, we could do something like the following:

1. Add a signature field to the various JSON schemas.
2. Initially fill in that field with a placeholder value like gpgsignature.
3. Serialize the JSON object as a single line string.
4. Generate a detached GPG signature of this string.
5. Encode the generated signature as a single-line JSON string.
6. Replace the placeholder value with the encoded signature.
7. Write out this final value as the actual git-notes entry.
8. Verifying the signature would then involve running that process in reverse.

This would mean that signing changes and checking signatures would be an optional feature that each individual community could decide for itself whether or not to adopt.

We should also provide some way of distributing the public GPG keys of contributors inside of the repository. The best approach would probably be to replicate the logic we are using in #88 for storing the list of forks in the repository.

[pittma]

Hey there!

I do believe this is a thing that my team'll need, so I'd love to take on this work. I intend to start digging around the code today to get a feel for how things work.