8000 Bug: `parse_wheel_filenames` accepts wheel filenames with unsorted compressed tag sets · Issue #909 · pypa/packaging · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Bug: parse_wheel_filenames accepts wheel filenames with unsorted compressed tag sets #909

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
woodruffw opened this issue May 15, 2025 · 0 comments
Open

Bug: parse_wheel_filenames accepts wheel filenames with unsorted compressed tag sets #909

woodruffw opened this issue May 15, 2025 · 0 comments

Comments

@woodruffw
Copy link
Member

Hello packaging maintainers!

I'm filing this as a bug report for some observed behavior.

TL;DR: parse_wheel_filename appears to allow compressed tag sets (defined in PEP 425) to appear in any order, while the PEP and living spec both require the order to be "sorted" (my emphasis below):

To allow for compact filenames of bdists that work with more than one compatibility tag triple, each tag in a filename can instead be a ‘.’-separated, sorted, set of tags. For example, pip, a pure-Python package that is written to run under Python 2 and 3 with the same source code, could distribute a bdist with the tag py2.py3-none-any.

(Permalinks: https://peps.python.org/pep-0425/#compressed-tag-sets and https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#compressed-tag-sets)

This can be seen by using parse_wheel_filename to parse a wheel whose compressed tags are out of order:

from packaging.utils import parse_wheel_filename

name = "pyvirtualcam-0.13.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl"
parse_wheel_filename(name)

Actual behavior

The above call yields:

('pyvirtualcam', <Version('0.13.0')>, (), frozenset({<cp310-cp310-manylinux_2_17_x86_64 @ 4370315200>, <cp310-cp310-manylinux2014_x86_64 @ 4370315520>}))

Expected behavior

I expected the above the raise a (subclass of) ValueError, since the compressed tag set appears in the wrong order in the wheel's filename.

The right order would be: pyvirtualcam-0.13.0-cp310-cp310-manylinux2014_x86_64.manylinux_2_17_x86_64.whl.

Additional context

This was noticed due to an interaction of a few different components in pypi/warehouse#18128:

  1. A user built a wheel (named pyvirtualcam-0.13.0-cp310-cp310-linux_x86_64.whl);
  2. They called auditwheel repair on the wheel, which re-tagged it as pyvirtualcam-0.13.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl). This tag ordering is incorrect per PEP 425, and is being tracked against auditwheel with Compressed tag sets are not sorted when rewriting wheel filename. auditwheel#583;
  3. packaging doesn't warn or fail with the new wheel distribution name, per this bug report;
  4. pypi-attestations then "ultranormalized" the wheel name for signing purposes, fixing it up to pyvirtualcam-0.13.0-cp310-cp310-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
  5. Finally, the end user attempted to retrieve their provenance metadata via https://pypi.org/integrity/pyvirtualcam/0.13.0/pyvirtualcam-0.13.0-cp310-cp310-manylinux2014_x86_64.manylinux_2_17_x86_64.whl/provenance and were confused when it wasn't present (since it's actually present at https://pypi.org/integrity/pyvirtualcam/0.13.0/pyvirtualcam-0.13.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl/provenance)

TL;DR: multiple components behaved in slightly different ways here, resulting in maximum confusion:

  1. auditwheel repair produced an incorrect tag ordering;
  2. packaging silently honored that incorrect tag ordering, causing PyPI to also honor it;
  3. pypi-attestations attempted to "fix" it per PEP 425, leading to a correct tag ordering but one that confused the user (since all other components used the invalid-but-accepted one). This last part has been fixed with fix: remove ultranormalization of distribution filenames trailofbits/pypi-attestations#124

See also #873 for a related (but different) issue in wheel filename parsing 🙂

CC @di for viz
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@woodruffw
0