On Wed, Mar 30, 2016 at 04:19:49PM -0000, Ralf Senderek wrote: > In case of an incident where the private key may be compromized, upstream > is required to build the trust into the new key from the ground up. > > As these cases can be quite complicated and would need some serious actions > on behalf of the packager I think at the moment everything speaks in favour or > SHOULD, because we don't have a bullet-proof procedure everyone can follow.
Exactly. The maintainer has to *decide* if she trusts the new signing key (either by reaching out to the authors through some side channel, or inspecting the code, or extending the web-of-trust). Alternatively, if the new tarball is not signed, the maintainer has to decide if she trusts the explanation for the lack of signature. Either way, this has to be done *before* the updated version is built. And then we're back to the old situation: there's either a (newly) trusted signature, and it MUST checked in %prep, or there's no signature for valid reasons, or the new tarball is rejected and not built. 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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
