search

hynek / build-and-inspect-python-package

Build and Inspect Python Packages in GitHub Actions
MIT License
181 stars 13 forks source link

Sigstore signing? #105

Closed henryiii closed 6 months ago

henryiii commented 8 months ago

Would it make sense to have a sigstore signing option?

https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#signing-the-distribution-packages

(Someone could download, sign, then reupload, but this seems like the sort of thing that could be integrated)

hynek commented 8 months ago

I don't have time to read up on this, but I'm open to PRs.

blaisep commented 6 months ago

ok you guys may be ahead of me, I was going to ask if you have already considered hardened runners, like https://github.com/wolfi-dev/wolfi-act ? (and yes, I can prepare a PR if needed)

from https://github.com/jazzband/help/issues/364#issuecomment-2135089642

webknjaz commented 6 months ago

Would it make sense to have a sigstore signing option?

Don't. Just don't. Integrating it into the action means giving the entirety of the build dependency tree access to OIDC. It is intentional that builds are to be performed in a job separate from uploading, and I've always emphasized this in the docs and on other avenues. This is why my guide that you linked, and the one William contributed to GitHub's own docs, demonstrate such separation in the examples.

Giving OIDC to the dist build job enables privilege elevation in systems other than PyPI through build dependency poisoning in PyPI-related jobs. Such things shouldn't be hidden from the end-user, who would then get confused on how something like AWS (or anything else OIDC-integrated, really) they plugged to a repository got compromised when they thought they weren't actually doing anything with it.

On that note, there will be attestations built into my pypi-publish action soon'ish (as it already uses OIDC for tokenless publishing), which is why William didn't copy the signing job example when contributing the OIDC/Trusted Publishing doc to GitHub. He's already started a draft PR against the action, the Twine PR has been merged and released last week and the Warehouse bits are still in the works. But I'd expect more progress after June 5.

To summarize, while the intention is good, I believe this actually opens up a can of worms vulnerability-wise, if integrated into this action.

henryiii commented 6 months ago

Excellent information, thanks!