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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
