Description of problem: Since the packaging changes made for bitcoin-core 25.0, a program extracted from the source tarball – verify.py – is used to verify the signatures on that same tarball. The thing that's supposed to be authenticated is allowed to assert that it is authentic. That's useless. If an attacker crafts a malicious source tarball, they will include a malicious verify.py that pretends to verify the signatures and feigns success. Thus the verification step is neutered, and the build will continue as if the malicious tarball had been verified. Version-Release number of selected component: 25.0-1.fc39
This is the upstream method, with the difference that the official way is to download the binaries/tarballs/gpgkeys on the fly, which we are not allowed to do: https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md The last example of the readme file is exactly that. I preferred the old method but I could not make it work. Patches are welcome!
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
(In reply to Simone Caronni from comment #1) > This is the upstream method, with the difference that the official way is to > download the binaries/tarballs/gpgkeys on the fly, which we are not allowed > to do: > > https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/ > README.md > > The last example of the readme file is exactly that. For verify.py to download a tarball, it must exist on your computer before the tarball is downloaded. It can't be extracted from a tarball it hasn't yet downloaded. Thus there is no circular reasoning in the upstream method. The circular reasoning is in the way verify.py is used by the RPM spec file. README.md doesn't specify how you're supposed to obtain and verify verify.py. The pathnames in the examples assume that you already have a whole source tree. The instructions at https://bitcoincore.org/en/download/ don't mention verify.py. They tell you to run gpg and sha256sum manually. Thus it looks like upstream's idea is that you should do the verification step by step manually the first time, and later upgrade by using your existing and previously verified copy of verify.py to download and verify the new tarball. That's obviously not great for packaging. > I preferred the old method but I could not make it work. The previous method wasn't optimal – it was locale-dependent and required a signature for every key – but I don't see why it would have stopped working for version 25. The signature scheme is the same, with the files SHA256SUMS and SHA256SUMS.asc, so verification should work the same way as it did for the previous version. Could you be more specific? What error did you get? You could use gpgverify followed by sha256sum, although that requires a key for every signature. It appears that gpgv isn't designed for a usecase with many signatories some of which might not be trusted. If there are any signatories you'd rather not trust, then you could delete their signatures from SHA256SUMS.asc. That's fairly easy to do when each signature is separately ASCII-armored. It doesn't harm security because the remaining signatures still prove that the checksum file was signed with trusted keys. The current gpgverify requires a single keyring, but if https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 gets merged, you'll be able to keep separate key files in the package instead. That way, when you add a trusted key, it will be much easier for others to verify that the other keys are unchanged. That's important because the whole signing concept hinges on continuity in the keys.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
The useless circular reasoning is still present in Rawhide.
And patches are still accepted :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.