Restore --verify-commits functionality

[jeffweiss]

Related to the discussion in #13, after we figure out a way to retrieve and trust keys, we'll want to re-add --verify-commits.

[nathanaschbacher]

This requires the tsign-ing of the Root key by people, correct? Let's set a process and deadline for that to happen.

[jeffweiss]

Either a tsign or ltsign, yes. Depending on whether we want the trust from employees -> root to be publicly visible or not. We'll also have to come up with a solution for trusting external contributors, like those on OSCC.

[nathanaschbacher]

I think that it makes sense to have it be a tsign instead of ltsign, it provides some openness to the verification process to be able to see that people have trusted the PolySync Root key. It also makes it a bit easier to deal with a DR situation where we have to revoke or reprovision Root I think.

For external contributors we should probably have two different processes...

1. For where we believe we can sufficiently verify the identity of a contributor (like a contractor, etc.) and accept signed+RSL changes from them directly.
2. For where we can't sufficiently verify their identity but we have a defined process of having a proxy (trusted PolySync employee, etc.) inspect and validate the contribution and then sign+RSL them as a batch themselves on the contributor's behalf.
   1. A version of this process could also be used for initially adopting other open source software that needs to be specially trusted. As well as for times when we need to sync w/ upstream.

[jeffweiss]

For external contributors without a contract, we'll have to decide what to do for those who have signed commits. Those who have not signed commits is fairly straightforward:

• A PolySync proxy must rebase their branch, leaving Author with the contributor's info and replacing Committer with their info and signing the commit (the default action during a rebase).

If a contributor has signed their commits; however, we need to decide between

• Keeping those signatures and trusting that committer (even a low level of trust)
• Rebasing and overwriting their commit signatures

[nathanaschbacher]

That sounds sensible... we should capture that in the How-To, and on the latter issue let's do both, but set criteria for each case. Because I could see on low-value, non-critical-path projects allowing a lower-level trust to suffice for measurement and traceability reasons.

[gchronis]

In order to turn on the verify commits functionality again, we need to wait until trust is distributed among the developers. According to the authors of the RSL paper, we can use the RSL to distribute trust among contributors.

Developers’ keys may be distributed using
trust/revoke RSL entries. To use these entries,
the repository is initialized with an authoritative root of trust
(usually a core developer) who will add further entries
of new developers in the group. Once developers’ public
keys are added to the RSL, they are allowed to add other
trust entries.
A trust entry contains information about the new developer
(i.e., username and email), her public key, a hash
of the previous push entry and a signature of the entry by
a trusted developer. Revocation entries are similar in that
they contain the key-id of the untrusted developer, the
hash of the push entry, and the signature of the developer
revoking trust.

If new trust entries have been added (by trusted developers) since the last fetch, secure-fetch can take a moment to import that key/those keys using gpg utilities.