Add bitcoin-core 24.0.1

[kaladinlight]

• updated gpg keys
• removal of kvaciral key
• updated file location of compat.h (alpine build)
• removed AR_FLAGS sed command (univalue no longer exists and secp256k1 was no-op)
• updated build and readme to reflect new version

[kaladinlight]

@andrewtoth dockerfile updated to v24.0.1

[andrewtoth]

Should we pin the sha256 hash for the downloaded tar files as well? Like https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L13 and https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L21? That way we can be sure we downloaded the right file.

[kaladinlight]

Should we pin the sha256 hash for the downloaded tar files as well? Like https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L13 and https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L21? That way we can be sure we downloaded the right file.

I think I will follow the existing pattern unless @ruimarinho would like to change things up.

[szokeptr]

Is there something blocking this PR?

[ruimarinho]

I’ll take a look today and merge. Sorry for the delay.

[W4545]

Is there a status update on this PR?

[ruimarinho]

I'm working on reviewing and testing https://github.com/ruimarinho/docker-bitcoin-core/pull/132 right now before I merge this one.

[ruimarinho]

Should we pin the sha256 hash for the downloaded tar files as well? Like https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L13 and https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/22.0/Dockerfile#L21? That way we can be sure we downloaded the right file.

This what SHA256SUMS does - it checks any file on its list (ie. bitcoin-24.0.1.tar.gz matches hash 12d4ad6dfab4767d460d73307e56d13c72997e114fad4f274650f95560f5f2ff).

Since we are verifying that SHA256SUMS has not been tampered by checking its signature against one of the gpg keys listed above, we can ensure the sha256 match is genuine. Please let me know if the implementation appears to suggest otherwise.

[andrewtoth]

If one of the signers has been compromised they could upload a signed SHA256SUMS which has a hash of a different binary they also upload. Since we know the hash now we can pin it so this attack cannot work in the future.

[ruimarinho]

That problem seems to have been mitigated by Peter Todd from bitcoin-core already - by providing a timestamped verification on the blockchain using the published ots file. The only problem is that it needs a local node to verify it, so it's not easy to add that into a CI pipeline.

Ideally bitcoin-core would published multiple detached signature so we could achieve something like a "multisig" approach where multiple members would have to be compromised for the attack to work.

[andrewtoth]

Sure, but it seems like the simplest solution is to pin the hash in the dockerfile. That way we don't even need to do any signature verification.

[ruimarinho]

Merged in https://github.com/ruimarinho/docker-bitcoin-core/commit/6da5bc0ef21e98f9a5940329666a96f2209d8c7c with SQLite support! Thank you so much for your help @kaladinlight and apologies to everyone for the successive delays here.

[ruimarinho]

@andrewtoth to guarantee that the current hashes are genuine, I'll need to do the ots verify check.

[andrewtoth]

There has also been discussion recently about hosting the binaries somewhere other than bitcoincore.org. By pinning the hash the binary could be sourced from anywhere and guaranteed to be correct.

[andrewtoth]

Yes, you can do the ots check once yourself, but it doesn't have to go in the dockerfile.