https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #24 from Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> --- (In reply to marco from comment #23) > If you fetch the key from the same website the binaries are taken from, > there is no security. Anyone replacing the binaries can trivially replace > the key. That would be true if the upstream project would generate a new key for every release, and also wouldn't sign their keys. When a new release is signed with the same key that the developers have been using for years, then that increases our confidence that it is from the same source as all the previous releases. When a key needs replacing, then the project can maintain continuity by signing the new key with the old key. We packagers must be very careful when a release-signing key changes, and not blindly replace the key like we replace a tarball. In this particular case you're also off the mark because my patched spec *doesn't* fetch the key from the same website as the binaries. To my slight surprise I found that the tarball from Github is identical to the one on bitcoin.org (and on bitcoincore.org). If that's reliable, then we can improve security by fetching the tarball from Github and the signed checksum file from bitcoin.org or bitcoincore.org, and verifying them with the key we already have. An attacker will then have to acquire the secret key and compromise *both* websites before they can sneak malicious changes past the verification step. > Also, bitcoincore.org is the official download site (bitcoin.org is a mirror > site unrelated to the Bitcoin Core project). In that case the URL field in the package should also point to https://bitcoincore.org/en/about/. > The instructions recommend to fetch the key based on its fingerprint > (01EA5486DE18A882D4C2684590C8019E36C2E964). Hmm, they refer to keyserver.ubuntu.com, which runs Hockeypuck. I don't see any statement that Hockeypuck has a solution to the spam attack (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) that led to keys.fedoraproject.org being turned off (https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/COEYWJBQDAWRSYNQW7Y7TD2EKEGBWOAY/) in February this year. If it doesn't then you expose yourself to a denial of service when you fetch from the keyserver. In case somebody thinks that fetching a key from a keyserver is more secure than fetching it from the project's website: It's not, because anyone can write somebody else's name on a key and upload it to a keyserver. Only the fingerprint ensures that you get the right key, and someone who can replace files on the project's website can replace the fingerprint too. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
