https://bugzilla.redhat.com/show_bug.cgi?id=1834731
--- Comment #120 from Simone Caronni <negativo17(a)gmail.com> ---
(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