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
Currently we accept OIDC tokens for which the aud claim contains our required audiences (pypi or testpypi respectively), however this doesn't preclude the aud claim from containing other audiences, because PyJWT will verify any token that simply contains the requested audience: https://github.com/jpadilla/pyjwt/blob/master/jwt/api_jwt.py#L335-L336.
The potential issue is that for a provider like CircleCI, the OIDC token could be shared across multiple 3rd party services with multiple audiences. This means that a CircleCI use that wants to use a token for both aud=pypi and aud=some_other_provider only gets a single token that would be valid for either audience, which means the other provider technically gains the ability to publish to PyPI as a result.
To mitigate this, we should restrict our verification of OIDC tokens to those that only specify our audience for the aud claim.
(While we're at it, we should also update the tests around our JWT verification to do less mocking/stubbing of the 3P library we're using here)
The text was updated successfully, but these errors were encountered:
This was raised as a result of CircleCI's OIDC implementation and related discussion here: sigstore/fulcio#591 (comment).
Currently we accept OIDC tokens for which the
aud
claim contains our required audiences (pypi
ortestpypi
respectively), however this doesn't preclude theaud
claim from containing other audiences, because PyJWT will verify any token that simply contains the requested audience: https://github.com/jpadilla/pyjwt/blob/master/jwt/api_jwt.py#L335-L336.The potential issue is that for a provider like CircleCI, the OIDC token could be shared across multiple 3rd party services with multiple audiences. This means that a CircleCI use that wants to use a token for both
aud=pypi
andaud=some_other_provider
only gets a single token that would be valid for either audience, which means the other provider technically gains the ability to publish to PyPI as a result.To mitigate this, we should restrict our verification of OIDC tokens to those that only specify our audience for the
aud
claim.(While we're at it, we should also update the tests around our JWT verification to do less mocking/stubbing of the 3P library we're using here)
The text was updated successfully, but these errors were encountered: