Integrating pypitoken to restrict tokens

[ewjoachim]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

The ticket may be early-stage, but I'd love to start the discussion.

As you may or may not know, PyPI API tokens have this very cool property that the bearer is autonomous to create restricted versions of their token. For example, if someone uses a "user" pypi token, they can generate a token that only works for one specific project. Doing this before used to be a little complicated because the restriction format was not very well documented.

Enter pypitoken. It's a new library (disclaimer: I'm the author) that aims to be the source of truth regarding PyPI tokens. I've made a PR for Warehouse (pypi) to start using this library to generate and check the tokens, and I've launched a discussion for the lib to become an official PyPA tool.

Now, whether any of this happens or not, I believe we could already start seeing if we would be able to automatically restrict tokens in Poetry, if it's something you folks would be interested in.

As of today, the only type of restriction supported by PyPI is projects restriction, but other types of restrictions are planned for the future (such as version number, filename and file hash).

The gain in security for Poetry would be mainly that tokens stolen in transit (MITM, ...) would be much less susceptible to be used to upload malicious distributions.

In terms of implementation, this is probably something we would want to kick-in only when the target is pypi (or testpypi) and the username in __token__. We could analyze existing restrictions on the token and add the relevant ones.

I'd totally understand if you think this is too much and you'd prefer the publish feature to stay simple, but at least, we'd have discussed this :)

PS: I suggested this to Twine too.

[abn]

Thank you for raising the issue. However, I am struggling to figure out what this brings to the table for poetry users. I am also a bit unclear on how the user flow here looks like.

As far as I can tell; a user who wants this can simply generate a new restricted token via your cli (?) and use that when adding repository credentials.

Can these tokens be generated on the fly and expired in really short periods of time (eg: 60 seconds)?

[ewjoachim]

Thank you for raising the issue. However, I am struggling to figure out what this brings to the table for poetry users.

Haha 😅 , sorry that my initial message lacked clarity.
There were 2 things suggested in the original ticket:

1. As another protection protecting tokens in transit which TLS already mitigates, this was discussed when implementing those tickets as belt & braces (especially when the braces are mostly free). Yes, I'm not convinced this is something we absolutely need given TLS is there, it's just that now that the tokens were created with the feature of being restrictable, it makes sense to restrict them as much as possible before transmitting them.
2. We imagine the possibility of letting users add caveats that require the bearer to send a 2FA token. In this case, poetry could detect this and request the 2FA token from the user

I am also a bit unclear on how the user flow here looks like.
As far as I can tell; a user who wants this can simply generate a new restricted token via your cli (?) and use that when adding repository credentials.
Can these tokens be generated on the fly and expired in really short periods of time (eg: 60 seconds)?

I haven't made a CLI but I might at some point. Yes users could do it beforehand but that is only if they know about the feature. Embedding it in the tool brings the benefit to everyone. For me the flow is that when Poetry knows all the details of the distribution file and identifies that the token is a PyPI api token, it adds all the available restrictions. This does not change the fact that in a CI, you'll need to store an unrestricted token, so it doesn't really help with token storage.

For now the only available restriction type is project, but it's planned to add additional restrictions. Of course it's perfectly sensible to just avoid taking a decision on this until the restrictions are available.

[Secrus]

This is highly unlikely to be included in Poetry itself (especially with Trusted Publisher feature being available) and sounds more like a plugin candidate to me.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.