Thanks so much @woodruffw for opening this discussion!
So others know how I’m thinking of this proposal in particular, I am conceptualizing this more as “Trusted Publisher receipts”. PyPI already verifies this same information w/ Trusted Publishers and there are useful properties we can take advantage of today and build on by exposing that same information in a consumer-verifiable way. This shouldn’t exclude the creation of other mechanisms of verifying the integrity of a Python distribution, the end-goal isn’t to have an integrity mechanism that works for all use-cases or to push everyone to use Trusted Publishers.
I provided reviews already to get this proposal into its current state, so I’ll only copy things I think are important:
- I don’t think we should copy the NPM publish provenance UI, I believe the framing there presents itself as providing integrity of the source commit which is true, but mostly for the workflow and not necessarily the package source code (you need to review the workflow itself to make that determination). We don’t want to give the indication that publish provenance means you can review the git tags safely without also reviewing the publishing workflow.
- Will and I have discussed the build provenance point raised by @davidism, I believe this proposal can be gracefully expanded to also include build provenance when that is defined for Trusted Publisher platforms PyPI supports.
An aside, to show that I am thinking of the non-OIDC build integrity case (but don’t have the spoons to work on it now), there are some primitives getting worked on that could be used together to provide widespread build integrity without needing public source code or a platforms with a PKI team (but doesn’t have the properties described in this proposal, like linking source repository to an artifact). The primitives I’m thinking about are build reproducibility (either byte-for-byte or semantically equivalent) combined with third-party observations about releases/distributions on PyPI. This approach would be a completely different route with more dependencies and involved parties than this proposal, this section is only to show that this use-case is being thought about by someone. 