API tokens: Remove @token and pypi: cases

[woodruffw]

At some point in the future (perhaps at the end of the API token beta?), support for @token as a token username and pypi: as a token prefix should end in favor of __token__ and pypi-, respectively.

See #6287, #6342.

cc @brainwane @di @ewdurbin @dstufft

[brainwane]

I'm in favor of doing this before the end of the beta, so that we can tell beta testers to try the new token usernames and prefixes, so we can find out during the beta whether the new ones cause any glitches.

[fschulze]

would it be too much to just reserve the "token" username? Is it already in use? GitHub does that for things like "issues" etc.

[hugovk]

Looks like the token username is unused: https://pypi.org/user/token/

[graingert]

@fschulze @hugovk you want something that other pypis eg devpi can use so you want something that was impossible to register previously

[pradyunsg]

I’ve gone ahead and squatted that name.

Obviously, I’m cool with just removing that account or let PyPI admins do whatever they deem necessary with that name.

[graingert]

how about '🎟' as the username? eg "\N{ADMISSION TICKETS}"

[fschulze]

@graingert what does the pypi.org username have to do with devpi? The devpi push command needs the pypi credentials anyway when used for pypi release.

[graingert]

@fschulze devpi would probably want to support this API token authentication scheme too. If an install has a user called "token" it would break that user for them. I'm thinking downstream "twine upload -r devpi" not upstream pypi

[fschulze]

@graingert it would use separate credentials anyway as it already does now. I don't see any reason accounts on pypi would interfere with devpi or the other way around.

[graingert]

Yes but the "token" username is part of the API tokens Auth protocol

[fschulze]

@graingert yes and it doesn't matter in devpi, because the API is specific to pypi.org. Otherwise all users in devpi would conflict with pypi.org already. If we implement upload tokens in devpi, then we would handle that on the devpi side. It is pretty easy to determine whether a token was used or not. Any token user in devpi would not interfere, because we can check whether we got a token or not by inspecting or validating it. So twine would work with devpi as soon as we would add token support and we wouldn't even have to block the token user name.

[woodruffw]

It's ultimately the maintainers' call, but I'm 👎 on plain token (or similar) for a few reasons:

1. Semantically, tokens are not passwords, so it doesn't make sense for them to have a valid username associated with them (apart from their relationship to the bearing user). The only reason we have a "username" at all in the scheme is backwards compatibility with Authorization: basic -- IIUC, the eventual plan is to update tools like twine and setuptools to use Authorization: token <macaroon> directly.
2. Similarly, it's especially confusing to have a valid, different username (e.g., the squatted token) built into the validation scheme for all users' tokens.
3. ^token or similar is a lot easier to search for than token.

[graingert]

Is there a regex of currently valid PyPI usernames so we can be more informed when picking an intentionaly invalid one?

[graingert]

https://github.com/pypa/warehouse/blob/fe4b61d3e9f9bea4fa037de4aa17fac6599b63c2/warehouse/accounts/models.py#L60-L66

[graingert]

so some examples:

_token, -token, .token
token_, token-, token.

and my personal favorite:
__token__

[graingert]

tokentokentokentokentokentokentokentokentokentokentoken is also an invalid username because it is too long

[pradyunsg]

__token__ me likey.