https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #120 from Simone Caronni <negativo17@xxxxxxxxx> --- (In reply to Björn Persson from comment #117) > bitcoin-gpg.sh relies on the tarball to tell it which keys should be used to > verify the tarball. A manipulated tarball will of course contain a > manipulated keys.txt that lists fake keys generated by the attacker. This > makes it all the more important to not remove and re-add keys in the package > unnecessarily. The continuity of the keys in the Git history becomes the > only thing that can show that the tarball is genuine. I can also move the SHA256SUMS checks in the script, but this is true for any package for which we verify hashes/signatures in Fedora. That's why you have the URL pointing to external files to check if they're the same. > bitcoin-gpg.sh will include a revoked or expired key if it signs a release. > Such keys must be weeded out. They can be removed only by running it at a specific time. Might be that keys are valid today and not valid in a few days. So up to the packager to execute when at least bumping release. > bitcoin-gpg.sh fails for me because the string "Good signature" is > locale-specific. The locale-independent solution is to use --status-fd and > grep for "^\[GNUPG:\] GOODSIG ". Good point, will adjust. (In reply to Warren Togami from comment #119) > It is so excessively slow that it inteferes with the ability of packagers to > incrementally improve this package. > The test suite is NOT USED FOR THE OFFICIAL UPSTREAM RELEASE PROCESS. That > strongly suggests that we shouldn't do it here either. I don't get what's issue you have with those. It is not excessively slow on recent hardware; I'm mostly using a 5 year old desktop and they all run fine. It's the builders who do the work, not the packager. And they can also be disabled for a quick test. These are handy to catch specific bugs introduced by compilers, compiler flags etc, so there is a lot of value in those. And packaging guidelines as well state that if the software supports checks we should add them. Would you be more comfortable knowing that actually functional tests fail every time but we package the software anyway? -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1834731 _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
