mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 20:12:57 +01:00
35ad97b8a3
bd6a24307564a56d54d98331d5e1680d27ddc09e script: Add Keyserver to verify-commits README (Emil Engler) Pull request description: When I use the option with the default keyserver on `gpg (GnuPG) 2.2.12` from the Debian repositories only the keys from meshcollider and fanquake are actually found. Using the ubuntu keyserver works without any problems and all keys are getting found. As this keyserver is also suggested on [https://bitcoincore.org/en/download/](), it would be good to have a common keyserver. ACKs for top commit: laanwj: ACK bd6a24307564a56d54d98331d5e1680d27ddc09e, better to be explicit here Tree-SHA512: d4127c42490390bed4e0074ebb1f8a6cc983f96bbea0ec1da011a93bed325a7f465ed9936e4bc2ef7c4b2e4501a2868d00b67ceb7bf85f2a902db9c6173a6c61
58 lines
2.7 KiB
Markdown
58 lines
2.7 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 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:
|
|
|
|
```sh
|
|
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](https://gnupg.org/) may be used to import the trusted keys by running the following command:
|
|
|
|
```sh
|
|
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.
|