With my upstream hat on, I'm all for a MUST, because it's the only way that
upstream can control what goes into Fedora. Without checking signatures or
tarball hashes, it's too easy to end up with questionable code.
But the MUST has some implications:
1) The packager's trust-building activities into the public key are by no
means optional.
2) Patches, that are applied to the signed (and checked) source must also be
signed by the packager and checked in %prep.
From an ordinary Fedora user's point of view modifications of the trusted
source code should also be properly attributed to the one who modified.
If upstream signs its code it is for the purpose to better distinguish
original and patched code. So in order to add accountability, patches must be
signed as well.
3) While the new tarball can be a URL, the public key ring cannot be allowed
to be downloaded, it must be produced by the packager and added as a file
to the SOURCE directory.
We have to ensure the equivalent to "certificate pinning" in browsers here,
so that a (possibly MITMed) false source tarball can be checke with a key
that has been sitting in the GIT for a long time, and not just been downloaded
alongside the false tarball.
Zbigniew Jędrzejewski-Szmek wrote:
The alternative of SHOULD would mean that the maintainer is not sure
if the new tarball can be trusted but goes ahead anyway. In that
situation I'd prefer she waits until it *can* be verified.
Zbyszek
You're right, its not easy to come up with a valid excuse not to check the
signature, when upstream clearly wants to use it, and highlights this fact on
their website. I'm just not sure how many packagers would get into trouble
if the signature check becomes a requirement for the package to go ahead.