dash/contrib/verify-commits/README.md
Wladimir J. van der Laan 568b7e1c0c
Merge #12822: Revert 7deba93bdc and fix expired-key-sigs properly
9471576 [verify-commits] Add some additional useful documentation. (Matt Corallo)
de7e931 Add Marco-expired-key-signed-commits to allow-revsig-commits (Matt Corallo)
99f6d48 Revert "test: Update trust git root". (Matt Corallo)

Pull request description:

  7deba93bdc was took the wrong approach to updating verify-commits for a key expiration. Namely, adding each commit to allow-revsig-commits should have been done instead, allowing them to still be validated, but with the expired key.

Tree-SHA512: 9fdc67eda8f6daa95082f6c1a2af81beb730a9ff3f8cf930bb2311fe29b5f05e1f89259aba5f112153ca2e9c62577cf60d31b4c8e9ac1bf3f5506e78f8401378
Signed-off-by: pasta <pasta@dashboost.org>

# Conflicts:
#	contrib/verify-commits/allow-revsig-commits
2020-10-22 11:36:39 -04:00

48 lines
2.4 KiB
Markdown

Tooling for verification of PGP signed commits
----------------------------------------------
This is an incomplete work in progress, but currently includes a pre-push hook
script (`pre-push-hook.sh`) for maintainers to ensure that their own commits
are PGP signed (nearly always merge commits), as well as a script to verify
commits against a trusted keys list.
Using verify-commits.sh safely
------------------------------
Remember that you can't use an untrusted script to verify itself. This means
that checking out code, then running `verify-commits.sh` against `HEAD` is
_not_ safe, because the version of `verify-commits.sh` that you just ran could
be backdoored. Instead, you need to use a trusted version of verify-commits
prior to checkout to make sure you're checking out only code signed by trusted
keys:
git fetch origin && \
./contrib/verify-commits/verify-commits.sh origin/master && \
git checkout origin/master
Note that the above isn't a good UI/UX yet, and needs significant improvements
to make it more convenient and reduce the chance of errors; pull-reqs
improving this process would be much appreciated.
Configuration files
-------------------
* `trusted-git-root`: This file should contain a single git commit hash which is the first unsigned git commit (hence it is the "root of trust").
* `trusted-sha512-root-commit`: This file should contain a single git commit hash which is the first commit without a SHA512 root commitment.
* `trusted-keys`: This file should contain a \n-delimited list of all PGP fingerprints of authorized commit signers (primary, not subkeys).
* `allow-revsig-commits`: This file should contain a \n-delimited list of git commit hashes. See next section for more info.
Key expiry/revocation
---------------------
When a key (or subkey) which has signed old commits expires or is revoked,
verify-commits will start failing to verify all commits which were signed by
said key. In order to avoid bumping the root-of-trust `trusted-git-root`
file, individual commits which were signed by such a key can be added to the
`allow-revsig-commits` file. That way, the PGP signatures are still verified
but no new commits can be signed by any expired/revoked key. To easily build a
list of commits which need to be added, verify-commits.sh can be edited to test
each commit with BITCOIN_VERIFY_COMMITS_ALLOW_REVSIG set to both 1 and 0, and
those which need it set to 1 printed.