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.

Not sure if you're asking how to specifically do this for CPython, or how this works generally with Sigstore.

For how this works specifically with CPython, see https://www.python.org/download/sigstore/ for details.

For how this works generally: it's the same public/private key cryptography you're used to elsewhere, and https://docs.sigstore.dev/ has more details.

Quite the opposite: keys are generated once per signing event, and the private key never leaves memory.

How can I search PyPI? It's not listed at https://sourcegraph.com/contexts with the other repositories.

Yep: https://pypi.org/help/#pronunciation

Bad copy/paste

Here's what it looks like:

    $ traceroute cv6.poinsignon.org
    traceroute to cv6.poinsignon.org (2001:bc8:3eff:c0::ff), 30 hops max, 80 byte packets
     1  gateway  0.795 ms  0.789 ms
    [...]
     8  hello (2001:bc8:3eff:c0::1)  1.431 ms  1.202 ms
     9  My.name.is.Louis.Poinsignon (2001:bc8:3eff:c0::2)  1.649 ms  1.274 ms
    10  I.am.a.network.and.systems.Engineer (2001:bc8:3eff:c0::3)  1.695 ms  2.090 ms
    11  This.is.my.resume.over.traceroute (2001:bc8:3eff:c0::4)  1.698 ms  1.793 ms
    12  o---Experience---o (2001:bc8:3eff:c0:ee::)  1.829 ms  2.052 ms
    13  2018.Cloudflare.NetworkEngineer.SF (2001:bc8:3eff:c0:ee::cf3)  2.261 ms  2.155 ms
    14  2017.Cloudflare.NetworkEngineer.London (2001:bc8:3eff:c0:ee::cf2)  2.293 ms  1.284 ms
    15  2016.Cloudflare.NetworkEngineer.Intern.SF (2001:bc8:3eff:c0:ee::cf1)  1.136 ms  1.205 ms
    16  2015.CEA.SoftwareEngineer.Intern.France (2001:bc8:3eff:c0:ee::cea)  1.204 ms  1.226 ms
    17  o---Education---o (2001:bc8:3eff:c0:ed::)  1.360 ms  1.607 ms
    18  2015-2016.DrexelUni.Exchange.CE.Philadelphia (2001:bc8:3eff:c0:ed::1)  1.237 ms  1.312 ms
    19  2011-2016.UTT.Master.CE.France (2001:bc8:3eff:c0:ed::2)  1.492 ms  1.604 ms
    20  o---Skills---o (2001:bc8:3eff:c0:51::)  1.565 ms  1.418 ms
    21  C.Java.Python.Golang (2001:bc8:3eff:c0:51::1)  1.364 ms  1.536 ms
    22  Net.Linux.Automation (2001:bc8:3eff:c0:51::2)  1.381 ms  1.266 ms
    23  Statistics.Maths.Photoshop (2001:bc8:3eff:c0:51::3)  1.504 ms  1.431 ms
    24  o---Various---o (2001:bc8:3eff:c0:7a::)  1.461 ms  1.519 ms
    25  Swimming.and.karate (2001:bc8:3eff:c0:7a::1)  1.378 ms  1.473 ms
    26  Piano (2001:bc8:3eff:c0:7a::2)  1.552 ms  1.683 ms
    27  o---Contact---o (2001:bc8:3eff:c0:c0::)  1.551 ms  1.486 ms
    28  mail.jobs.at.poinsignon.org (2001:bc8:3eff:c0:c0::1)  1.576 ms  1.473 ms

Using hash checking mode: https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

Straight from the horse's mouth, if you prefer: https://docs.python.org/3.11/whatsnew/3.11.html

PyPI supports uploading GPG signatures. Nobody uses it.

From https://github.com/psf/requests/issues/6140:

The domain is still owned by Kenneth and the maintainers haven't had access to it in quite some time.

and:

For those looking for alternatives, https://requests.readthedocs.io/en/latest/ should be returning docs correctly again. This has been the "official" location for some time as we lack controls on the python-requests domains. I'll update again once we receive a response from Kenneth.

Łukasz Langa now works full time on CPython via the PSF's Developer in Residence program.

https://pyfound.blogspot.com/2021/07/ukasz-langa-is-inaugura...

https://archive.md/1q3hv