bitcoin

mirror of https://github.com/bitcoin/bitcoin.git synced 2024-11-19 18:09:47 +01:00

History

glozow 873dcc1910 Merge bitcoin/bitcoin#27058 : contrib: Improve verify-commits.py to work with maintainers leaving `14fac808bd` verify-commits: Mention git v2.38.0 requirement (Andrew Chow) `bb86887527` verify-commits: Skip checks for commits older than trusted roots (Andrew Chow) `5497c14830` verify-commits: Use merge-tree in clean merge check (Andrew Chow) `76923bfa09` verify-commits: Remove all allowed commit exceptions (Andrew Chow) `53b07b2b47` verify-commits: Move trusted-keys valid sig check into verify-commits itself (Andrew Chow) Pull request description: Currently the `verify-commits.py` script does not work well with maintainers giving up their commit access. If a key is removed from `trusted-keys`, any commits it signed previously will fail to verify, however keys cannot be kept in the list as it would allow that person to continue to push new commits. Furthermore, the `trusted-keys` used depends on the working tree which `verify-commits.py` itself may be modifying. When the script is run, the `trusted-keys` may be the one that is intended to be used, but the script may change the tree to a different commit with a different `trusted-keys` and use that instead! To resolve these issues, I've updated `verify-commits.py` to load the `trusted-keys` file and check the keys itself rather than delegating that to `gpg.sh` (which previously read in `trusted-keys`). This avoids the issue with the tree changing. I've also updated the script so that it stops modifying the tree. It would do this for the clean merge check where it would checkout each individual commit and attempt to reapply the merges, and then checking out the commit given as a cli arg. `git merge-tree` lets us do basically that but without modifying the tree. It will give us the object id for the resulting tree which we can compare against the object id of the tree in the merge commit in question. This also appears to be quite a bit faster. Lastly I've removed all of the exception commits in `allow-revsig-commits`, `allow-incorrect-sha512-commits`, and `allow-unclean-merge-commits` since all of these predate the commits in `trusted-git-root` and `trusted-sha512-root`. I've also updated the script to skip verification of commits that predate `trusted-git-root`, and skip sha512 verification for those that predate `trusted-sha512-root`. ACKs for top commit: Sjors: ACK `14fac808bd` glozow: Concept ACK `14fac808bd` Tree-SHA512: f9b0c6e1f1aecb169cdd6c833b8871b15e31c2374dc589858df0523659b294220d327481cc36dd0f92e9040d868eee6a8a68502f3163e05fa751f9fc2fa8832a		2023-02-27 13:17:48 +00:00
..
allow-incorrect-sha512-commits	verify-commits: Remove all allowed commit exceptions	2023-02-16 12:46:59 -05:00
allow-revsig-commits	verify-commits: Remove all allowed commit exceptions	2023-02-16 12:46:59 -05:00
allow-unclean-merge-commits	verify-commits: Remove all allowed commit exceptions	2023-02-16 12:46:59 -05:00
gpg.sh	verify-commits: Move trusted-keys valid sig check into verify-commits itself	2023-02-16 12:46:40 -05:00
pre-push-hook.sh	scripted-diff: Bump copyright headers	2021-12-30 19:36:57 +02:00
README.md	verify-commits: Mention git v2.38.0 requirement	2023-02-21 17:00:13 -05:00
trusted-git-root	Revert "[contrib] verify-commits: Add MarcoFalke fingerprint"	2023-02-21 14:00:13 +01:00
trusted-keys	Revert "[contrib] verify-commits: Add MarcoFalke fingerprint"	2023-02-21 14:00:13 +01:00
trusted-sha512-root-commit
verify-commits.py	verify-commits: Skip checks for commits older than trusted roots	2023-02-16 12:47:00 -05:00

README.md

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.

Unless --clean-merge 0 is specified, verify-commits.py will attempt to verify that each merge commit applies cleanly (with some exceptions). This requires using at least git v2.38.0.

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 hkps://keys.openpgp.org --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.