2016-06-09 19:55:12 +02: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
|
2018-11-26 16:22:36 +01:00
|
|
|
are PGP signed (nearly always merge commits), as well as a Python 3 script to verify
|
2016-06-09 19:55:12 +02:00
|
|
|
commits against a trusted keys list.
|
|
|
|
|
|
|
|
|
2018-05-10 18:22:58 +02:00
|
|
|
Using verify-commits.py safely
|
2016-06-09 19:55:12 +02:00
|
|
|
------------------------------
|
|
|
|
|
|
|
|
Remember that you can't use an untrusted script to verify itself. This means
|
2018-05-10 18:22:58 +02:00
|
|
|
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
|
2016-06-09 19:55:12 +02:00
|
|
|
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:
|
|
|
|
|
2018-11-26 16:22:36 +01:00
|
|
|
```sh
|
|
|
|
git fetch origin && \
|
|
|
|
./contrib/verify-commits/verify-commits.py origin/master && \
|
|
|
|
git checkout origin/master
|
|
|
|
```
|
2016-06-09 19:55:12 +02:00
|
|
|
|
|
|
|
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.
|
2018-03-29 16:31:56 +02:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2018-11-26 16:22:36 +01:00
|
|
|
Import trusted keys
|
|
|
|
-------------------
|
|
|
|
In order to check the commit signatures you must add the trusted PGP keys to your machine. This can be done in Linux by running
|
|
|
|
```sh
|
|
|
|
gpg --recv-keys $(<contrib/verify-commits/trusted-keys)
|
|
|
|
```
|
|
|
|
|
2018-03-29 16:31:56 +02:00
|
|
|
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
|
2018-05-10 18:22:58 +02:00
|
|
|
list of commits which need to be added, verify-commits.py can be edited to test
|
2018-03-29 16:31:56 +02:00
|
|
|
each commit with BITCOIN_VERIFY_COMMITS_ALLOW_REVSIG set to both 1 and 0, and
|
|
|
|
those which need it set to 1 printed.
|