https://bugzilla.redhat.com/show_bug.cgi?id=1834731



--- Comment #24 from Björn Persson <bj...@xn--rombobjrn-67a.se> ---
(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/de...@lists.fedoraproject.org/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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to