<blockquote>
<p>I have then ran <code>gpg --verify SHA256SUMS.asc SHA256SUMS</code> and when I do this, gpg is reporting multiple keys are <code>not certified with a trusted signature - there is no indication that the signature belongs to the owner</code> - providing an exit status code of 2.</p>
</blockquote>
<p>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.</p>
<p>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).</p>
<p>This <a href="https://security.stackexchange.com/q/147447">security.SE question</a> goes into further detail.</p>

CC BY-SA 4.0
2022-04-29T08:14:55.210Z
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
CC BY-SA 4.0
2022-04-29T16:04:16.557Z
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.
Ava Chow
CC BY-SA 4.0
2022-04-29T16:05:49.167Z
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.
Ava Chow
CC BY-SA 4.0
2022-04-29T20:22:04.103Z
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
CC BY-SA 4.0
2022-04-28T14:50:03.607Z
2022-04-28T14:50:03.607Z
Ava Chow
<p>I have precisely followed the instructions for attempting to verify the latest 23.0 release of <code>bitcoind</code> on Linux, available here: <a href="https://bitcoincore.org/en/download/" rel="nofollow noreferrer">https://bitcoincore.org/en/download/</a></p>
<p>I have gpg imported all the keys defined here:</p>
<p><a href="https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/builder-keys/keys.txt" rel="nofollow noreferrer">https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/builder-keys/keys.txt</a></p>
<p>I have then ran <code>gpg --verify SHA256SUMS.asc SHA256SUMS</code> and when I do this, gpg is reporting multiple keys are <code>not certified with a trusted signature - there is no indication that the signature belongs to the owner</code> - providing an exit status code of 2.</p>
<p>My script therefor does not proceed to download and unpack the latest <code>bitcoind</code> binary.</p>
<p>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?</p>
<p>Thank you.</p>
<p><strong>UPDATE</strong></p>
<p>There are also several <code>can't check signature: no public key</code> errors on the gpg verification output so this is probably the main cause of the problem.</p>

<bitcoind><verification><pgp>
Unable to verify Bitcoin 23.0 release due to developer keys being untrusted/uncertified
parkamark
# Unable to verify Bitcoin 23.0 release due to developer keys being untrusted/uncertified

(Asked by: username_0 on 2022-04-28)

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.

**Tags:** bitcoind, verification, pgp


---

## 1 answers

### Answer by username_1 on 2022-04-28. Score: 6 | Accepted answer

> 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](https://security.stackexchange.com/q/147447) goes into further detail.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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.  
> **username_1**: 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.  
> **username_0**: 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.  

---

