Proposal: Support for Private Packages on PyPI Using Existing Token System (original) (raw)

Hello everyone! 👋

I’d like to propose a native way for PyPI to support private packages, available only to authorized users authenticated via the existing token system.

Today, PyPI supports token-based authentication for uploading packages, which already includes features like scoped permissions and user management. However, there is no official support for restricting download access to a package — all published packages are public by default.

My proposal is to allow project maintainers to mark a package as private, making it accessible only via a valid authentication token. For example, installation could work like this:

pip install --extra-index-url https://__token__:<TOKEN>@pypi.org/simple my-private-package

:brain: Benefits:

This could be handled on the server side with a visibility flag (public/private) per project, scoped token access, and proper 403/401 responses for unauthorized download attempts.

I understand this may have architectural or policy implications, and I’d love to hear the community’s thoughts! :heart:

Let me know if this kind of proposal would be better structured as a PEP, and I’m happy to collaborate and refine the idea further.

EWDurbin (Ee Durbin) May 3, 2025, 1:27am 2

Cross posted from your GitHub issue:

Hi! This is a great idea that is softly on our roadmap at some point for Organization accounts.

The main blocker is primarily ensuring that we execute it in a way that doesn’t interfere with the donated services that make PyPI possible.

Ultimately it is much larger of a project than a single issue can capture, and will require more legal, financial, and administrative work than changes to warehouse itself.

To do this, the existing token system first needs to support fine grained permissions (or at the very least some way of creating read only tokens).

"Using " the “Existing Token System”

would allow anyone with permission to download the private PyPi package, to also push code to it.

image

I couldn’t find a way to create a read only token anyway.

Other services are available, but a Github private repo, with a fine grained read-only PAT will handle this nicely already for sdists (I’ve not had any need to build private wheels yet). The only difference for the user is the URL.

barry (Barry Warsaw) May 3, 2025, 8:43pm 4

This seems to overlap with stage previews proposed in PEP 694. The idea being if you create an upload session, you probably want to preview that staged release before you publish it.

The way this is proposed, you, the uploader can decide at the time the session is created, whether stage previews will be easily guessable or obscured, depending on whether you’ve included a nonce of your own. Normally, a session token is generated by hashing the package name and version, but if a nonce is given, then that contributes to the hash, and thus gives the session owner the ability to obscure the session. There’s still no authentication required to access it, and this was an important design decision because there currently isn’t any authentication framework for index downloading.

That could change if something like what’s proposed here leads to authentication for downloading. Also, if something like this proposal leads to --extra-index-url which is token based, then both this proposal and PEP 694 should converge on a scheme that would work for both.