On 30 March 2016 at 15:45, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:

On Wed, Mar 30, 2016 at 02:44:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote:
> [snip the part I complete agree with]
>
> > Having said the above, I also advocate a SHOULD instead of a MUST in
> > the guidelines as providing a signature with the source tarball is
> > voluntary for upstream and should be viewed as an additional means
> > to maintain the integrity of the code that should be honoured in the
> > spec file.
> What the upstream does is something that we cannot control, and we can
> only encourage the upstream to DTRT.
>
> In fact signatures and license files are quite similar:
> our guidelines say that the license file MUST be installed if provided
> by upstream, and packagers SHOULD ask upstream to provide it if it is
> missing [1]. I think we should follow this pattern for signatures.
>
> There will always be exceptions to the "MUST check if signed" rule:
> repacking the tarball is an obvious one. The guidelines should
> acknowledge this.
>
> Zbyszek

[1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

--

Granted on LICENSE but that is about providing providence on the open source nature and demonstrating permission to distribute.

Given the legalities surrounding that and the potential damage to Fedora (and possibly Red Hat) for non-free items being distributed that's a somewhat different situation to verifying that the tarball in the lookaside cache is the same as that which an original upstream provided.

For this reason (alongside the others about repack) I really do think that should signature verification be added to the guidelines the best way to handle that would be:

"If the upstream provides a signed archive this SHOULD be verified in %prep prior to unpacking"

Start off with that - if we find that the use of this starts growing (again how many packages in the archive actually have signed tarballs right now?) then this can always be modified in the future to a MUST if it becomes apparent that it has saved us somewhere. I'm really reluctant to add another thing that needs to go to FPC for an exception though (which would be the case with a MUST) just after we've come to an agreement on the bundling side of things having *removed* exception requirements for that.