dash/contrib/verify-commits
laanwj 2ce8f7716f
Merge bitcoin/bitcoin#25197: contrib: Remove keys that are no longer used for merging
d4b3dc5b0a726cc4cc7a8467be43126e78f841cf contrib: Remove keys that are no longer used for merging (Hennadii Stepanov)

Pull request description:

  See:
  - https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-21#726591
  - https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-12-09#750000

  Also updated `trusted-git-root` to be right after **meshcollider**'s last merge.

  The latest similar change was bitcoin/bitcoin#7713.

  A related discussion on [IRC](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727090):
  > [12:28](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727090) \<MarcoFalke> jonasschnelli: I was about to ask you whether you planned to remove your fingerprint from the "trusted-keys" for merging, but it looks like this will break verify-commits ...
  > [12:31](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727091) \<laanwj> you would also have a add all his merge commits to exceptions, i guess
  > [12:32](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727092) \<laanwj> or patch the script to allow different key for different ranges of commits
  > [13:15](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727118) \<jonasschnelli> MarcoFalke: I had no plan to remove my keyid,… would that make sense and how would you fix verify commits?
  > [13:16](https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-10-22#727119) \<jonasschnelli> Ideally, we should set en expiration date next to those keyid

ACKs for top commit:
  laanwj:
    ACK d4b3dc5b0a726cc4cc7a8467be43126e78f841cf

Tree-SHA512: 6c23c932288b56b546a9ba45288205fae063e3f98ff308393acffd5d79eb5097417de1c3d8e865a3f66734740ca2388b2452c3c810e45cdf3b15ccfa215f574e
2024-01-14 11:05:37 -06:00
..
allow-incorrect-sha512-commits Merge #13066: Migrate verify-commits script to python, run in travis 2021-05-06 12:06:09 +03:00
allow-revsig-commits
allow-unclean-merge-commits Merge #13066: Migrate verify-commits script to python, run in travis 2021-05-06 12:06:09 +03:00
gpg.sh Merge #17829: scripted-diff: Bump copyright of files changed in 2019 2023-12-06 11:40:14 -06:00
pre-push-hook.sh Merge #18673: scripted-diff: Sort test includes 2023-08-29 22:00:59 -05:00
README.md Merge #17637: script: Add Keyserver to verify-commits README 2021-09-14 14:30:21 -04:00
trusted-git-root Merge bitcoin/bitcoin#25197: contrib: Remove keys that are no longer used for merging 2024-01-14 11:05:37 -06:00
trusted-keys Merge bitcoin/bitcoin#25197: contrib: Remove keys that are no longer used for merging 2024-01-14 11:05:37 -06:00
trusted-sha512-root-commit Merge #9940: Fix verify-commits on OSX, update for new bad Tree-SHA512, point travis to different keyservers 2019-02-26 16:41:05 -06:00
verify-commits.py Merge #17829: scripted-diff: Bump copyright of files changed in 2019 2023-12-06 11:40:14 -06:00

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 Python 3 script to verify commits against a trusted keys list.

Using verify-commits.py safely

Remember that you can't use an untrusted script to verify itself. This means that checking out code, then running verify-commits.py against HEAD is not safe, because the version of verify-commits.py 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.py 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.

Import trusted keys

In order to check the commit signatures, you must add the trusted PGP keys to your machine. GnuPG may be used to import the trusted keys by running the following command:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys $(<contrib/verify-commits/trusted-keys)

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