On 30 Mar 2016 13:15, "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl> wrote:
>
> On Wed, Mar 30, 2016 at 07:01:53AM +0100, James Hogarth wrote:
> > And of course with the packager uploading both the key and the archive to
> > git with no net access in koji to verify the key I really don't see what
> > this actually gives us
>
> The signature and key can be verified by anyone. The signature key
> usually changes only rarely, and dist-git history is immutable, so you
> easily can check that the key is the same one that has been used to signed
> previous releases by looking at git history, which is already useful
> by itself.
>
> By expending a bit more effort, you can do a verification of the key
> once in some side channel (e.g. using the network or some local web-of-trust),
> and then only check that this key hasn't changed in dist-git. If the
> key ever changes, this is a reason for suspicion and a careful check.
>

But by the same line of thinking you can just use grab the tarball yourself and compare to the sources in dist-git to verify upstream matches local (as the fedora-review tool does).

And from there you rapidly venture siren the same Web of Trust issues anyway.

> > beyond a heads up to a sleeper maintainer that he
> > doesn't have an official tarball when built locally...
>
> I don't think you can discount this. Most maintainers don't check the
> tarballs they download if they build fine, afaik. Checking the
> signatures in %prep would force a significant change to how we build
> srpms.
>
>

That perhaps is a valid case to an extent, but it really does seem reaching for the edge to find a reason for it.

Now don't think there's any harm in shipping the gpg key and doing a verification but I don't think it should be a mandatory guideline.

Have the guideline state "if the upstream provides a signed archive then this SHOULD be verified in %prep" rather than a must... Add the appropriate review entry to go with it and add a macro with standardised naming to make it convenient.

That would be much better than a MUST and would avoid FPC exceptions if there were reasons the tarball can't be distributed.

We trust our packagers to do a lot, we can trust them to add this to their packages if it helps them and for them to encourage it in their reviews if they find a signed archive provided upstream.

How many packages is this really going to affect anyway? Would be interesting if there was a convenient way to tell.