@dstufft Thank you for the very long and comprehensive reply, I really appreciate the explanation!
I admit that I have not considered the amount of trust that PyPI places in the CI engine. In retrospect, it makes sense given the data available to PyPI, this is just not something I thought about as a consumer. (Can any CI engine really publish any project at all, not just any project with Trusted Publishing configured for that particular CI provider? I would have hoped that the latter reduces the blast radius at least somewhat, not that it fundamentally changes much.)
I broadly agree with your evaluation of Codeberg’s CI service. There are some things that surprise me (as an e.V. member and contributor but not someone with a formal position), like the lack of security@, which I will likely raise internally, but overall and with some knowledge of how it is operated, I would say this is more or less accurate. I think evolving the CI service in a direction where it would be stable and secure enough to consider Trusted Publisher support would be excellent in general, although I don’t think there is currently enough staffing to do that.
Thank you for bringing up the fact that the API tokens are Macaroons! I have a passing familiarity with Macaroons (I’ve never used them but I’ve skimmed the paper before); it should not be too difficult to write a bit of code to add the caveats I need. This will fulfill essentially all of my personal requirements for Codeberg/PyPI integration. While losing attestation is a bit unfortunate, I have to admit that I’ve never been able figure out how to verify the signatures, and I feel that the technology is not mature enough for widespread use anyway (as in: I don’t expect any of my downstream users to bother verifying attestation).
I will post the code I’ll use to add caveats here when I come up with it.