chore: floor urllib3 in the [eth] extra - #593
Open
Zyrtnin wants to merge 1 commit into
Open
Conversation
pyrxd does not import urllib3. It arrives two levels down — web3 requires requests>=2.23.0, which requires urllib3<3,>=1.26 — so `pip install pyrxd[eth]` pulls it whether we mention it or not. urllib3 below 2.7.0 carries two advisories: PYSEC-2026-141, where a proxied cross-origin redirect forwards sensitive headers, and PYSEC-2026-142, a decompression bomb via Brotli streaming or drain_conn. HYGIENE, NOT A FIX, and the comment in pyproject.toml says so. Measured on 2026-09-03: brotli is not installed, `drain_conn` appears in 0 files across web3/requests, and web3 uses `stream=True` at 0 sites — so the decompression issue is unreachable. The header leak's vulnerable call DOES exist (requests/adapters.py:651 passes assert_same_host=False through a ProxyManager), but reaching it needs a configured proxy AND a hostile redirect from the RPC endpoint, and no exploit was demonstrated. By this repo's review rule that makes it a path, not a finding. The floor is here so a consumer's own pip-audit is not handed a finding by our extra. Owning a constraint on a package we do not import has a real cost — it can conflict with a consumer's tree — so it is the only such floor, and the comment says to remove it once requests floors urllib3 itself. Compatible with requests' own range: 2.7.x satisfies both <3,>=1.26 and >=2.7.0. Found by pip-audit during the security review. Worth noting the triage nearly went wrong: the first dependency-closure walk parsed "urllib3>=1.21.1,<3" with `.split()[0]`, kept the version specifier as part of the name, matched nothing, and concluded the package was unreachable. The chain is real. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pyrxd does not import urllib3. It arrives two levels down —
web3→requests→urllib3<3,>=1.26— sopip install pyrxd[eth]pulls it whether we mention it or not.Versions below 2.7.0 carry two advisories:
drain_connHygiene, not a fix — and the comment in
pyproject.tomlsays soNeither is reachable through pyrxd's usage, measured on 2026-09-03:
drain_connappears in 0 files across web3/requestsstream=Trueat 0 sitesThe header leak's vulnerable call does exist —
requests/adapters.py:651passesassert_same_host=Falsethrough a ProxyManager — but reaching it needs a configured proxy and a hostile redirect from the RPC endpoint. No exploit was demonstrated, so by this repo's review rule that is a path, not a finding.The floor exists so a consumer's own
pip-auditis not handed a finding by our extra.The cost, stated
Owning a constraint on a package we do not import can conflict with a consumer's tree. It is the only such floor, and the comment says to remove it once
requestsfloors urllib3 itself. Compatible with requests' own range — 2.7.x satisfies both<3,>=1.26and>=2.7.0.A near-miss in the triage
The first dependency-closure walk parsed
urllib3>=1.21.1,<3with.split()[0], kept the version specifier as part of the package name, matched nothing, and concluded urllib3 was unreachable from the consumer closure. It is not. Redone withpackaging.requirements.Requirement.CI-equivalent locally: 10,993 passed, 192 skipped, 1 xfailed.
🤖 Generated with Claude Code