Open Mr0grog opened 5 months ago
This discussion implies that something might show up somewhere (not clear where) in GH's UI when using this, which would be nice: https://github.com/orgs/community/discussions/122028#discussioncomment-9312273
Looks like this is getting built into hynek/build-and-inspect-python-package
, which we use: https://github.com/hynek/build-and-inspect-python-package/pull/122
Closing this, since I don’t think there’s much for us to do here.
@Mr0grog FYI I documented why it's better to use a separate job with elevated privileges over in https://github.com/hynek/build-and-inspect-python-package/issues/105#issuecomment-2136262019. (Also, you didn't enable that feature anyway, as it needs a setting and more privileges set)
Ah, thanks for noting the security concern! Re-opening this since publishing attestations should not be part of publishing, not building.
GitHub recently released some fancy new “artifact attestation” actions that integrate with sigstore: https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/
If I understand correctly, these go into Sigstore’s public transparency log (since we are a public and not private project), which gives us nice, verifiable signatures for our sdists and wheels. (GitHub’s post talks about using the
gh
GitHub client to verify signatures, but again, IIUC, we should also be able to usecosign
or other verfiers, too — this doesn’t seem super worthwhile if those don’t also work.)There is also
sigstore/gh-action-sigstore-python
as documented over at PyPA: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#signing-the-distribution-packages . I suspect the new GitHub thing will probably include some more valuable metadata or add new stuff to the GitHub UI, but it’s also possible these are completely equivalent for [public] use case.Seems worth implementing, or at least investigating further, since it looks pretty simple to do.