You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spitballing a bit further (from a DM with @di): I think we could enable a variant of this by default for some Trusted Publisher providers: if a provider (like GitHub) provides IP ranges (either static or retrievable from an API endpoint) for their CI/CD service, then we could add a variant of the IP caveat that only permits token use from those IPs.
When a token exchange for a GHA-based Trusted Publisher comes in, PyPI adds a new caveat (e.g. allowed_ips: GitHubOnly) to the minted token before returning it to the user
The minted token behaves exactly the same as before, except that it's also exfiltration resistant (i.e., the attacker can't pull it from GHA and reuse it on another machine, such as their local machine).
In effect, this would more strongly bind the Trusted Publishing-issued credential to the lifecycle of the publisher that requested it -- the credential would be both short-lived, and couldn't be used outside of the service that we expect to use it.
On the other hand, the security benefit of this might be somewhat limited in the case of GitHub Actions: since any Actions IP would be valid, the attacker could just use the stolen credential from another GHA workflow on a repo they control.
The npm repository has the notion of an access/API token that can be optionally restricted by IP address ranges:
We could add a similar option, include it as a caveat on the token, and compare it with
remote_addr
when authenticating.The text was updated successfully, but these errors were encountered: