On 30 Mar 2016 13:15, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)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.