Link hashes are parsed from the query string, not only the URL fragment

[yonnnxr]

LinkHash.find_hash_url_fragment() searches the whole URL for
[#&](algo)=value, so a query-string parameter named after a hash algorithm is
read as a hash:

>>> from pip._internal.models.link import Link
>>> Link("https://example.com/pkg.whl?token=x&sha256=" + "a" * 64).has_hash
True

This only triggers when the parameter is not the first one: ?sha256=... alone
does not match, since the separator has to be # or &.

Two things suggest this is not intended:

1. _clean_link(), which decides whether two links are equivalent, reads only
   the fragment (urllib.parse.parse_qs(parsed.fragment)). The same URL
   therefore counts as hashed for pinning and as unhashed for equivalence.
2. The regex is named _hash_url_fragment_re; news/11936.bugfix.rst describes
   the change that introduced [#&] as "Fix and improve the parsing of hashes
   embedded in URL fragments"; and every case in test_link_hash_parsing uses
   #. The & alternative covers &-separated parameters inside the fragment
   (#subdirectory=setup&sha256=...), not a query.

Consequence: for a direct, user-supplied requirement,
InstallRequirement.hashes(trust_internet=False) includes the link's hash, so a
query value counts towards --require-hashes. Reproduced with the CLI against a
locally built wheel (no network):

$ cat req_query.txt
pkg @ file:///tmp/pkg-1.0.0-py3-none-any.whl?token=x&sha256=<digest>

$ python -m pip install --dry-run --no-index --no-deps --require-hashes -r req_query.txt
Processing /tmp/pkg-1.0.0-py3-none-any.whl
Would install pkg-1.0.0

$ cat req_nohash.txt
pkg @ file:///tmp/pkg-1.0.0-py3-none-any.whl

$ python -m pip install --dry-run --no-index --no-deps --require-hashes -r req_nohash.txt
ERROR: Hashes are required in --require-hashes mode, but they are missing from some requirements.

Per SECURITY.md this looks like a normal parser bug rather than a security
report, so I'm filing it here.

Is this divergence worth fixing? A patch that searches only
urlsplit(url).fragment keeps every documented form working, including
#subdirectory=setup&sha256=..., and makes the parser agree with _clean_link.
Happy to open a PR if so.

[yonnnxr]

Opened #14316 with the change described above.

[pfmoore]

Has this ever caused an issue in real-life usage?

[yonnnxr]

No, I don't have a real-world report, and I should be upfront about that. I
found this while reading how Link handles hashes, not from a failure.

What I do have is an internal inconsistency. _clean_link() reads hashes only
from the fragment (parse_qs(parsed.fragment)), while
find_hash_url_fragment() searches the whole URL. So the same URL is treated as
hashed for pinning and as unhashed for link equivalence. The regex is named
_hash_url_fragment_re, and the & alternative is there for &-separated
parameters inside the fragment (#subdirectory=setup&sha256=...), which is the
only form covered by test_link_hash_parsing. There is no test and no
documentation for a query parameter.

Where it would bite is a URL whose query is assembled by something other than the
person writing the requirements (a script, a lockfile generator, a CI template).
For a URL written by hand the author could have used #sha256= or --hash
anyway. I have no instance of that to point to.

The only behaviour change in #14316 is that a query-string <algo>= stops
counting as a hash. Every documented form is unchanged, and anything relying on
the query form under --require-hashes would now fail loudly with "Hashes are
required" rather than change silently.