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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
