2

I have precisely followed the instructions for attempting to verify the latest 23.0 release of bitcoind on Linux, available here: https://bitcoincore.org/en/download/

I have gpg imported all the keys defined here:

https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/builder-keys/keys.txt

I have then ran gpg --verify SHA256SUMS.asc SHA256SUMS and when I do this, gpg is reporting multiple keys are not certified with a trusted signature - there is no indication that the signature belongs to the owner - providing an exit status code of 2.

My script therefor does not proceed to download and unpack the latest bitcoind binary.

I don't believe I am doing anything wrong and I suspect this is a key hygiene issue that the devs need to get on top of. Is anyone else experiencing this issue, and if not, can provide some insight into a fix?

Thank you.

UPDATE

There are also several can't check signature: no public key errors on the gpg verification output so this is probably the main cause of the problem.

0

1 Answer 1

6

I have then ran gpg --verify SHA256SUMS.asc SHA256SUMS and when I do this, gpg is reporting multiple keys are not certified with a trusted signature - there is no indication that the signature belongs to the owner - providing an exit status code of 2.

This error is a result of how GPG determines whether it trusts keys. When a key is signed by another key, the signer indicates that they have verified that the key belongs to the person it claims is its owner. This property is transitive, to a degree (that is configured by you, locally). So if GPG sees a key signed by a key that you trust, then it will also indicate that you trust that key, even if you yourself have not signed it. You can also indicate (locally) to GPG that you trust a key, and with what level you trust it.

This particular error message means that the GPG does not see anything that indicates that it trusts those keys. It may mean that you have not signed someone's key who has signed those keys. It may be that your GPG simply does not have anything in its trust database and so it defaults to not trusting any key (this is the likely scenario for most users).

This security.SE question goes into further detail.

4
  • I imported all the keys and signed them as trusted, using keyserver.unbuntu.com. Re-ran gpg --verify and everything checks out except a single key that has expired. So yet again, I'm at a point where I cannot use this gpg verification method to verify the integrity of the download, even though it's recommended that this process be followed before running the bitcoind binary. It's a shame because I really wanted to go with this procedure for upgrading my bitcoin node but if the key hygiene of the developers is this flakey, it is never going to work.
    – parkamark
    Apr 29 at 8:14
  • 2
    The purpose of the multiple signatures is to allow people to be certain of the release even if they only trust one of the developers. There is no need to have all of the keys and verify all of the signatures. One signature being valid is sufficient to verify the integrity of the download. The multiple signatures just allows verifiers to choose which developer's key they want to do that verification with. If all of the signatures are valid and it's just one key that is expired, you have still verified the integrity of the download.
    – Andrew Chow
    Apr 29 at 16:04
  • 2
    Note how the instructions say "It is recommended that you choose a few individuals from this list who you find trustworthy and import their keys as above". This means that you don't have to verify all of the signatures in order to be sure that the binary you downloaded is correct.
    – Andrew Chow
    Apr 29 at 16:05
  • Ok great. I've implemented a mechanism to randomly select a single signature from SHA256SUMS.asc - it then uses that for verification. Not all the keys appear to be valid/are available so it will be hit and miss as to whether this step passes but, given I run this upgrade check daily, eventually it will pick a signature which offers a pass (thus exit code of 0) and then the upgrade of bitcoind will continue as normal (SHA256SUM download verification etc). Many thanks for your help @Andrew.
    – parkamark
    Apr 29 at 20:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.