di

Maven Central does not currently support OIDC-based authentication (commonly called "Trusted Publishing").

For some context on the scale of this grant, the PSF took in only $1M in "Contributions, Membership Dues, & Grants" in 2024: https://www.python.org/psf/annual-report/2024/

It says "September 23, 2025" right at the top.

Don't be embarrassed, it's a good book (and was my favorite too).

Note that https://peps.python.org/pep-0440/#direct-references says:

> Public index servers SHOULD NOT allow the use of direct references in uploaded distributions. Direct references are intended as a tool for software integrators rather than publishers.

This means that PyPI will not accept your project metadata as you currently have it configured. See https://github.com/pypi/warehouse/issues/7136 for more details.

This is why PyPI recommends using Trusted Publishing (https://docs.pypi.org/trusted-publishers/) which removes the need for long-lived tokens entirely.

That article is about the packaging summit talk on introducing namespaces, not about organizations. In fact, when talking about organizations, it explicitly says:

> But support for namespaces is not part of the new feature.

> An example of this is that PyPI just got the ability to namespace packages.

You're thinking of organizations, which are not namespaces: https://blog.pypi.org/posts/2023-04-23-introducing-pypi-orga...

Pip supports checksums too. A better link might be https://pip.pypa.io/en/stable/topics/secure-installs/

PyPI has never supported 2FA via SMS.

Periods are not prohibited in package names, they're just uncommon (e.g., https://pypi.org/project/zope.sqlalchemy/)

Gitlab also doesn't support customizable OIDC audiences yet: https://gitlab.com/groups/gitlab-org/-/epics/7335

Previous discussion: https://news.ycombinator.com/item?id=34464657

Author here: yep.

That's the point of the certificate authority and transparency log: it makes the public key known by publicly binding it to a verifiable identity.

A hash verifies integrity, but has no way to demonstrate any relationship to a signing identity. Signing is not just about integrity, but also being able to say _who_ generated the signature.

Nope. The private key is generated within the client each time a signing event occurs, and that's what is used to sign the artifact. It doesn't come from the certificate.

The certificate just binds the public key to the identity at a given point in time, in a public way. This certificate is generated every time you sign something, and is put in the transparency log.

There's a walkthrough of the process here that might be helpful: https://www.youtube.com/watch?v=jdf-gNYg0fw&t=494s

The certificate specifically demonstrates that the <release-manager>@python.org identity signed the artifact.

So there's a) no long-lived private key for them to lose (because it's never stored after signing) and b) a consumer doesn't need to find the right key PGP ID, verify (somehow) that that key ID is associated with a given release manager -- they can just trust that the release manager is in control of their @python.org identity.

Additionally, with PGP, you have no idea if your private key is being used somewhere else to generate valid signatures maliciously. With Sigstore, in order for the signature to be valid, it must be published in a transparency log, which is continuously monitored. So in the event of if the key/identity is compromised, the identity owner can be made aware immediately and the signature revoked.

More details are here: https://www.python.org/download/sigstore/ and here: https://docs.sigstore.dev/

Anyone can generate a hash. Signing with a private key means that only the owner of that private key was able to generate a given signature. Singing with a private key which was bound to a known identity via a signing certificate proves that only that identity was in possession of the signing key, during a very short window.

In this specific case, we can say that the artifacts in question were verifiably signed by owner of the <release-manager>@python.org identity.