"De novo" project creation via API tokens/OIDC

[woodruffw]

There's currently a little bit of friction around bootstrapping API tokens on a new PyPI project:

1. Prepare a package for a new project
2. Upload the first version of the project to PyPI using a user-scoped API token (not ideal for long-term actions) or user credentials (shouldn't be used in CI)
3. Log into PyPI and create a project-scoped token for the new project
4. Use the new project-scoped token for all future releases

A similar problem will happen with OIDC: we currently require a project to exist before an OIDC publisher can be registered against it, meaning that a user will have to upload at least one release with a user-scoped token or credentials before they can switch to a credential-less workflow.

Some potential solutions:

1. Allow users to pre-create projects on PyPI before uploading any releases.
   • Pros: Solves the "de novo" problem above.
   • Cons: Malicious users can abuse this as a low-friction way to squat names.
2. Allow users to pre-register OIDC publishers; on use, the project would be created for the first time.
   • Pros: Solves the "de novo" problem and minimizes squatting potential.
   • Cons: Complicates the OIDC data mode: pre-registering a publisher means either pre-creating the project (same problem as (1)) or creating a "symbolic" link to a nonexistent project (another column). We'd have to be careful about invalidating a publisher if someone else races/beats it to creating a project, so that someone can't quietly takeover a project's releases via OIDC.
3. Something else?

[woodruffw]

From discussions, I'm currently leaning towards solution (1).

Here's the proposed flow:

1. An already registered PyPI user who meets certain requirements can "pre-register" a project name via the Warehouse web UI
   • Some potential requirements: the account must be over a week old, must have a verified email, must have 2FA, etc.
2. Pre-registering is done in a new view + form, where the user specifies the name they'd like to pre-register.
3. If the name is available and passes PyPI's normal name restriction checks (e.g. for typosquatting) an empty project is created, with the user in the Owner role.
4. Simultaneously, a timer is begun: if the user does not upload a release to the project within the reservation timespan, the project is deleted entirely and released for anyone to use. This has the added effect of invalidating any tokens that the user might have minted (but not used) for the project, since the project ID (and user role) will no longer match.
   • Additionally, a user who allows the reservation period to expire could be temporarily locked out of other reservations for a short period, like 72 hours.

Additional considerations:

• No user should be able to pre-register more than a small handful of project names at once. 5 is probably a reasonable restriction, since it'll allow people uploading a handful of new projects to do them all at once.
• We could consider adding a "cooldown" period (with exponential backoff) for expired registration periods, to prevent people from squatting a name by cycling it between two accounts. This may be more work than it's worth, however, since namesquatting on PyPI is already easier than that.

[woodruffw]

Working on this this week.

[woodruffw]

Just some notes:

We'll probably want the button for this under the project management view (/manage/projects), i.e. somewhere on the top of this page:

...probably right below "Your projects," with language like "Reserve a project name." The button will be inactive if the user isn't eligible to reserve a project name (per the restrictions above).

Clicking that button should, in turn, produce a form modal (not a separate page, since it's pretty much a single input) that includes (1) the name to reserve, and (2) a confirmation checkbox ("I understand that this is a temporary reservation, and that I need to upload a package in the next XX hours to make it permanent"), plus a submit button.

Pressing the button should produce a success or error flash, as appropriate.

[woodruffw]

Current sketch:

As-is, I've dropped the plan for the modal: it doesn't add anything to the flow, and makes it less accessible.

[webknjaz]

Hi @woodruffw, it's great that this effort is getting revived. Have you seen the previous discussion and my previous suggestions @ #6378 (comment) + #6378 (comment).

It seems that people in the discussion agreed that it was a good idea, and it seems to partially align with what you're describing here. So I'm mostly just checking to see if you know about it and whether you're planning to incorporate those ideas.

[woodruffw]

I did, thanks! And thanks for cross-referencing as well.

I think the ultimate plan here is close to what you commented in that issue: we aren't planning single-use tokens, and instead we're going to make "reservations" part of the Warehouse UI. I'll have some initial work pushed up soon to demonstrate the rough idea there.

[woodruffw]

Demonstrating the "reserved" chip on a project:

[webknjaz]

@woodruffw that sounds roughly what I had in mind originally (except for the expiration part). Do you think the Reserve button could also automatically make a token so that it's not a two-step process but a single-step one?