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
TL;DR: The current https://docs.pypi.org/attestations/publish/v1 attestation type doesn't contain any domain separation for indices. This can result in unintended confabulation of attestations intended for different indices. For example:
foo/bar @ pypi.yml signs for sampleproject-1.2.3.tar.gz and uploads it to PyPI for normal users
foo/bar @ pypi.yml signs for sampleproject-2.0.0.tar.gz and uploads it to TestPyPI for beta users
sampleproject-2.0.0 contains bugs or security issues and is never uploaded to PyPI in its current form. It remains on TestPyPI.
The attacker manages to upload sampleproject-2.0.0 to PyPI.
Users inadvertently verify the attestation for sampleproject-2.0.0 and accept it, since the signing identity and subject are correct.
This attack scenario is pretty niche, since it requires the attacker to (1) obtain access to sampleproject on PyPI, and (2) have access to a legitimate-but-undesirable attestation to advertise on PyPI. This makes it much more likely than a "normal" supply chain compromise, e.g. where the attacker obtains access to sampleproject's source repository and produces a valid but malicious attestation therefrom.
At the same time, PyPI's attestation schema can and should prevent this niche case. One way to do this would be to publish a new attestation type, e.g. ``https://docs.pypi.org/attestations/publish/v1.1` or v2, which updates the `predicate` body from "must be empty" to something like:
"predicate": {
"audience": "pypi"
}
Where audience should then be checked by the verifier, if present, to match the index's audience (e.g. via the pre-existing Trusted Publishing /_/oidc/audience endpoint). Another option would be to have audience be a URL, although this would diverge from the current Trusted Publishing behavior.
The text was updated successfully, but these errors were encountered:
Filing as a breakout for #17001.
TL;DR: The current
https://docs.pypi.org/attestations/publish/v1
attestation type doesn't contain any domain separation for indices. This can result in unintended confabulation of attestations intended for different indices. For example:foo/bar @ pypi.yml
signs forsampleproject-1.2.3.tar.gz
and uploads it to PyPI for normal usersfoo/bar @ pypi.yml
signs forsampleproject-2.0.0.tar.gz
and uploads it to TestPyPI for beta userssampleproject-2.0.0
contains bugs or security issues and is never uploaded to PyPI in its current form. It remains on TestPyPI.sampleproject-2.0.0
to PyPI.sampleproject-2.0.0
and accept it, since the signing identity and subject are correct.This attack scenario is pretty niche, since it requires the attacker to (1) obtain access to
sampleproject
on PyPI, and (2) have access to a legitimate-but-undesirable attestation to advertise on PyPI. This makes it much more likely than a "normal" supply chain compromise, e.g. where the attacker obtains access tosampleproject
's source repository and produces a valid but malicious attestation therefrom.At the same time, PyPI's attestation schema can and should prevent this niche case. One way to do this would be to publish a new attestation type, e.g. ``https://docs.pypi.org/attestations/publish/v1.1` or
v2
, which updates the `predicate` body from "must be empty" to something like:Where
audience
should then be checked by the verifier, if present, to match the index's audience (e.g. via the pre-existing Trusted Publishing/_/oidc/audience
endpoint). Another option would be to haveaudience
be a URL, although this would diverge from the current Trusted Publishing behavior.The text was updated successfully, but these errors were encountered: