Adding to what Vitaly has said:
The other question is where you get those signatures from. If upstream does not sign
tarballs any more then there is nothing to check, sadly.
In a source-git based workflow, or if you roll your own using rpkg or such, you have the
upstream source available so that you can verify the signature of a commit or tag from
which you create a tarball. But, as Vitaly pointed out, builders have no way to check that
signature "against the tarball"; it does not match our workflow.
I'm not sure I understand upstream's workflow problem, though. Is attaching assets
to a github release cumbersome? If yes, and if they are suggesting to use a reproducible
automatic tarball (from the likes of `git archive`), then it should be simple to script
the following for their release process:
- download/build tarball from signed commit/tag
- sign the tarball
- tag the detached signature files as `%{name}-%{version}.sig` (tags can point to blobs),
or commit them to a sig branch, or put them into a note object attached to the release
commit or tag object, and push (if uploading/attaching as an asset) is too cumbersome
That way any downstream would have an upstream signature for "the" tarball
(without upstream having to "create and upload" one).
Michael