LCORE-1082: Bump-up urllib3 to 2.5.0 #883
Conversation
WalkthroughUpdated dependency pins across platform requirement files: Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
requirements.aarch64.txt(3 hunks)requirements.x86_64.txt(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-18T10:57:39.266Z
Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:59-59
Timestamp: 2025-08-18T10:57:39.266Z
Learning: In the lightspeed-stack project, transitive dependencies like faiss-cpu are intentionally pinned as top-level dependencies to maintain better control over the dependency graph and avoid version conflicts when bundling ML/LLM tooling packages.
Applied to files:
requirements.aarch64.txtrequirements.x86_64.txt
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
🔇 Additional comments (4)
requirements.aarch64.txt (1)
1384-1386: Verify kubernetes version alignment between aarch64 and x86_64 requirements.The reported downgrade from kubernetes 34.1.0 → 33.1.0 needs confirmation. Cross-reference requirements.aarch64.txt (line 1384) with requirements.txt or requirements.x86_64.txt to verify:
- Whether kubernetes is also 33.1.0 in the x86_64 file (if downgrade is consistent)
- Whether this aligns with the PR's stated scope of bumping urllib3 to 2.5.0
- If unintentional, restore kubernetes to 34.1.0 and re-compile both architectures
If the downgrade is intentional, document the specific incompatibility between kubernetes 34.1.0 and urllib3 2.5.0 in the PR.
requirements.x86_64.txt (3)
1960-1964: LGTM on “via” annotations.Only provenance comments changed; no version delta.
3571-3576: urllib3 2.5.0 bump is compatible with requests 2.32.5; link CVE fixes.This bump is safe: requests 2.32.5 supports urllib3 >=1.21.1,<3, so 2.5.0 is compatible. The 2.5.0 release addresses two moderate CVEs:
- CVE-2025-50181: PoolManager could fail to disable redirects when
retrieswas passed- CVE-2025-50182: Redirect controls were ignored in Pyodide/browser/Node.js environments
Both are patched in 2.5.0. Ensure other dependencies (botocore, conan, etc.) do not conflict by pinning urllib3 <2.x; verify your full dependency tree before merging.
1384-1386: Resolve urllib3 2.5.0 and kubernetes-client compatibility conflict.urllib3 2.5.0 introduces security fixes for CVE-2025-50181 and CVE-2025-50182, but kubernetes-client constrains urllib3 to <2.4.0 due to documented SSL failures (Python 3.13 + EKS) and packaging conflicts. Verify this pin is intentional (e.g., workaround via override, or testing compatibility relaxation) and document the rationale. If unintentional, either pin urllib3 to a kubernetes-client-compatible version or confirm kubernetes-client has been patched to support urllib3 2.5.0+.
| urllib3==2.5.0 \ | ||
| --hash=sha256:3fc47733c7e419d4bc3f6b3dc2b4f890bb743906a30d56ba4a5bfa4bbff92760 \ | ||
| --hash=sha256:e6b01673c0fa6a13e374b50871808eb3bf7046c4b125b216f6bf1cc604cff0dc |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check the current state of the codebase for pyproject.toml and requirements files
git ls-files | grep -E "(pyproject\.toml|requirements|setup\.py)" | head -20Repository: lightspeed-core/lightspeed-stack
Length of output: 208
🏁 Script executed:
# Search for existing urllib3 version constraints in the repo
rg "urllib3" --type-list
rg "urllib3" -t py -t txt -t toml -t yaml -t ini | head -30Repository: lightspeed-core/lightspeed-stack
Length of output: 208
🏁 Script executed:
# Check if there are any comments or discussions about urllib3 2.6.0 in the codebase
rg "2\.6\.0|2\.6|get_headers" -t py -t txt -t mdRepository: lightspeed-core/lightspeed-stack
Length of output: 208
🌐 Web query:
urllib3 2.6.0 breaking changes API removals what deprecated in 2.0
💡 Result:
Short summary.
-
urllib3 2.6.0 (breaking/removal): HTTPResponse.getheaders() and HTTPResponse.getheader(name, default) were removed (use HTTPResponse.headers / HTTPResponse.headers.get()). Security fixes limit chained content-encodings and harden compressed-stream handling; custom ContentDecoder API changed (update custom decompressors). Other small features/behavior fixes listed in the 2.6.0 changelog. [1]
-
What was deprecated in the 2.0 series (and intended for removal in later 2.x releases): HTTPResponse.getheaders()/getheader(); urllib3.contrib.pyopenssl and urllib3.contrib.securetransport modules; the urllib3[secure] extra; ssl_version option (use ssl_minimum_version); PoolManager.connection_from_context(strict) parameter; NewConnectionError.pool attribute; format_header_param_html5/format_header_param (use format_multipart_header_param); RequestField.header_formatter; HTTPSConnection.set_cert(); HTTPConnection.request_chunked(); plus other compatibility removals (Python ≤3.6, non‑OpenSSL TLS libs, fallback commonName hostname checks, default cipher list, etc.). See the v2.0 migration notes for the full list. [2]
Sources:
[1] urllib3 2.6.0 changelog.
[2] urllib3 v2.0 migration / changelog (deprecations & removals).
🌐 Web query:
kubernetes-client urllib3 compatibility 2.5.0 2.6.0
💡 Result:
Short answer: The official kubernetes-client (python) has historically been pinned to urllib3 <2.4.0 and there are open/recent issues showing incompatibilities with urllib3 2.4+ (so 2.5.0 / 2.6.0 are not yet universally supported). See the repo issues reporting breakage with urllib3 v2.4.0 and ongoing vulnerability/packaging discussions. [1][2][3]
What to do:
- If you need stability, keep urllib3 at a version the kubernetes package currently accepts (i.e., <2.4.0) until the client releases an update. [1][2]
- If you must run urllib3 2.5.0/2.6.0, test thoroughly (SSL/EKS edge-cases were reported) and watch the kubernetes-client PRs/issues for an official update. [2][3]
Sources:
- kubernetes-client/python issue: urllib3 v2.4.0 on Python 3.13 doesn't work with EKS. [1]
- kubernetes-client/python issues about urllib3 pinning and packaging. [2]
- urllib3 changelog (2.5.0 & 2.6.0 releases). [3]
urllib3 → 2.5.0: incompatible with the pinned kubernetes-client; requires thorough testing.
- urllib3 2.5.0 is compatible with Requests 2.32.5 (Requests has supported urllib3 2.x since 2.30.0).
- Critical issue: kubernetes-client is historically pinned to urllib3 <2.4.0 and has reported incompatibilities with urllib3 2.4.0+ (including 2.5.0), particularly with EKS integrations. Before merging, verify that kubernetes and related integrations actually work with 2.5.0 or update the kubernetes-client version to one that officially supports it.
- If this change has been tested with the full kubernetes client, confirm findings in the PR description. If not tested, run a quick import and EKS smoke test before merging.
🤖 Prompt for AI Agents
In requirements.aarch64.txt around lines 3574-3576, urllib3 was pinned to 2.5.0
which is known to be incompatible with many kubernetes-client versions (they
require urllib3 <2.4.0); either change the urllib3 pin to a compatible <2.4.0
version or upgrade the kubernetes-client dependency to a release that explicitly
supports urllib3 2.5.0, then run a quick verification (import the kubernetes
client, run an EKS smoke test and CI dependency tests) and document the test
results in the PR description so we know this change is safe to merge.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
pyproject.toml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
pyproject.toml
📄 CodeRabbit inference engine (CLAUDE.md)
pyproject.toml: Configure pylint withsource-roots = "src"
Excludesrc/auth/k8s.pyfrom pyright type checking
Files:
pyproject.toml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: build-pr
- GitHub Check: E2E: library mode / ci
- GitHub Check: E2E: library mode / azure
- GitHub Check: E2E: server mode / azure
- GitHub Check: E2E: server mode / ci
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
| "jsonpath-ng>=1.6.1", | ||
| "psycopg2-binary>=2.9.10", | ||
| "litellm>=1.75.5.post1", | ||
| "urllib3==2.5.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
urllib3 2.5.0 release security vulnerabilities
💡 Result:
Short answer: urllib3 2.5.0 fixed two moderate redirect-related issues (CVE-2025-50181 and CVE-2025-50182) but versions <2.6.0 (including 2.5.0) remain affected by an excessive-resource / chained Content-Encoding vulnerability (CVE-2025-66418). Upgrade guidance: upgrade to >=2.5.0 to get the redirect fixes, and to >=2.6.0 (or a version that lists CVE-2025-66418 as fixed) to remediate the compression chain resource issue.
Sources:
- urllib3 2.5.0 release notes (lists the two security fixes). [1]
- NVD / security advisories for CVE-2025-50181 / CVE-2025-50182 (redirect/SSR F / Pyodide issues). [2][3]
- CVE-2025-66418 (excessive resource consumption via chained Content-Encoding; affects >=1.24, <2.6.0). [4]
References:
[1] GitHub — urllib3 releases: 2.5.0.
[2] NVD — CVE-2025-50181 / CVE-2025-50182.
[3] Snyk advisory (CVE-2025-50181).
[4] ResolvedSecurity / CVE-2025-66418 entry.
Upgrade urllib3 to 2.6.0 or later to close open CVE.
Version 2.5.0 fixes CVE-2025-50181 and CVE-2025-50182 (redirect-related issues), but remains vulnerable to CVE-2025-66418 (excessive resource consumption via chained Content-Encoding, affecting all versions <2.6.0). For a CVE-fix PR, pin to 2.6.0 or a newer version that fully remediates all known vulnerabilities, or explicitly document why the intermediate version is chosen despite the unpatched CVE.
🤖 Prompt for AI Agents
In pyproject.toml around line 55, the urllib3 pin is set to 2.5.0 which remains
vulnerable to CVE-2025-66418; update the dependency spec to pin urllib3 to 2.6.0
or later (for example "urllib3>=2.6.0,<3.0") in the dependencies section to
ensure the CVE is remediated, and if you intentionally keep 2.5.0 for
compatibility, add a clear comment in the file explaining the rationale and an
action to upgrade as soon as compatibility is resolved.
1 participant
Description
LCORE-1082: Bump-up urllib3 to 2.5.0
Type of change
Tools used to create PR
Identify any AI code assistants used in this PR (for transparency and review context)
Related Tickets & Documents
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.