Add a small note about security implications of using cibuildwheel in CI runners

[agriyakhetarpal]

Based on recent discussions, this PR adds a small note for our users about the security implications of using cibuildwheel in their CI configuration. Suggestions on improving the language are welcome.

I also bumped actions/checkout to v6 everywhere, since they finally fixed the issue where it leaked credentials and previously required persist-credentials: false to avoid that; it no longer needs that now. However, it is possible that it may not be enough as people may not upgrade anyway if their Dependabot/Renovate/etc. is not configured or if their cadence is too low. I wonder if we should set that explicitly in our docs? Edit: I have set it explicitly indeed, as not enabling the option still makes it store credentials, just in a location that's a bit more resistant, and Zizmor dropped the severity of the rule for v6 and above and didn't remove the rule itself.

[henryiii]

See zizmorcore/zizmor#1353 - persist-credentials: false still is better than not having it, it's just persisted in a different location.

Bumping versions is always recommended, our examples should stay on the latest versions.

[agriyakhetarpal]

Ah, thanks for linking that one and clarifying – I had this in mind.

[agriyakhetarpal]

Done, thanks!

[joerick]

Thank you @agriyakhetarpal for doing this!

I think the best place for this warning will be at the end of the How it Works section in both the README and the docs index - it relates to the mechanism of building and the diagram provides some context.

As for the text of the warning, I think it would be good to make sure there's information specific to cibuildwheel, as well as some general advice as well. Essentially, the information from a threat model perspective is that cibuildwheel offers no isolation from the project it's building - even on Docker or Pyodide.

Here's a draft from me:

Building and testing wheels executes arbitrary code from your project and its dependencies. Although cibuildwheel uses OCI containers and Pyodide for some builds, these provide no security guarantees - the code you're building and testing has full access to the environment that's invoking cibuildwheel.

If you cannot trust all the code that's pulled in, maintain good security hygiene: keep the job that builds distributions separate from the job that uploads them to PyPI, handle secrets and credentials with care and rotate them regularly, and follow the principle of least privilege when granting permissions. Do not store sensitive data on CI runners.

Also, I removed the link to the PyPA guides - I couldn't see anything relevant to the security model of building in there.

[agriyakhetarpal]

Thank you @agriyakhetarpal for doing this!

I think the best place for this warning will be at the end of the How it Works section in both the README and the docs index - it relates to the mechanism of building and the diagram provides some context.

As for the text of the warning, I think it would be good to make sure there's information specific to cibuildwheel, as well as some general advice as well. Essentially, the information from a threat model perspective is that cibuildwheel offers no isolation from the project it's building - even on Docker or Pyodide.

Here's a draft from me:

Building and testing wheels executes arbitrary code from your project and its dependencies. Although cibuildwheel uses OCI containers and Pyodide for some builds, these provide no security guarantees - the code you're building and testing has full access to the environment that's invoking cibuildwheel.
If you cannot trust all the code that's pulled in, maintain good security hygiene: keep the job that builds distributions separate from the job that uploads them to PyPI, handle secrets and credentials with care and rotate them regularly, and follow the principle of least privilege when granting permissions. Do not store sensitive data on CI runners.

Thanks a lot @joerick, your proposed text reads much better to me overall! I'll move its location to the end of the "How it works" section as well. For the README, I'll keep it above the build options table, since it's fairly long.

Also, I removed the link to the PyPA guides - I couldn't see anything relevant to the security model of building in there.

Fair call; I was previously thinking that we should keep it because we have this page: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/, but I now notice that it itself indirectly links to our docs for advice on building platform-specific distributions.