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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
