Repository navigation
Bump vulnerable dependencies to minimum patched versions (uv.lock only) - #290
Merged
Rick Brighenti (rbrighenti) merged 3 commits intoOct 30, 2026
Conversation
Lockfile-only update that clears 92 of 93 open Dependabot alerts by moving each vulnerable package to its smallest patched version. Transitive bumps are limited to what the patched versions require. opentelemetry-api (#178) remains: the fix needs >=1.45.1 but google-adk caps opentelemetry at <=1.41.1 (1.x) / <=1.44 (2.x). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request. Check if the Files changed in this pull request are included in default exclusions.
Dependency ReviewThe following issues were found:
License Issuesuv.lock
OpenSSF ScorecardScorecard details
Scanned Files
|
Krishnadheeraj (DheerajPannala)
left a comment
Krishnadheeraj (DheerajPannala)
left a comment
Contributor
There was a problem hiding this comment.
Your targeted upgrade approach keeps the remediation easy to audit, and the explanation of the required transitive changes is clear.
Three minor comments below.
Outside the changed lines:
- Minor: Avoid making the sandbox's glibc requirement mandatory (
uv.lock:295). This new dependency makes the normal workspace installation fail on x86_64 Linux with Python 3.11/3.12 and glibc below 2.34, such as RHEL 8. The platform marker selects Hyperlight there, but its backend has only manylinux_2_34 Linux wheels and no source distribution. Consequently, uv cannot install the locked environment even when no sandbox functionality is used. - Minor: New wheel-only hyperlight backend makes
uv syncfail on x86_64 Linux with glibc < 2.34 (uv.lock:2527). Moving to agent-framework-core 1.11.0 brings inagent-framework-hyperlightthrough the[all]extra. On x86_64 Linux (and AMD64 Windows) with Python below 3.14, that in turn pullshyperlight-sandbox-backend-wasm==0.4.0. That package has no sdist. Its only wheels aremanylinux_2_34_x86_64andwin_amd64. So on x86_64 Linux hosts with glibc 2.28–2.33, the dev environment can no longer be installed. Examples are RHEL/Rocky/Alma 8, Debian 11 /python:3.1x-bullseyeimages and Ubuntu 20.04. Both plainuv sync(the setup step in docs/design.md) anduv sync --locked --all-extras --dev... - Minor: cryptography 50.0.0 entry drops the Intel-macOS and 32-bit Windows wheels, so those contributors now build from source (
uv.lock:1372). The 46.0.7 entry includedmacosx_10_9_universal2andwin32wheels. The 50.0.0 entry only hasmacosx_11_0_arm64for macOS andwin_amd64for Windows.uv synconly installs from the files listed in the lock. So contributors on Intel Macs, or on a 32-bit Windows Python, now build cryptography from the sdist. That needs a Rust toolchain plus OpenSSL headers; without them,uv syncfails. cryptography is in every dev environment: azure-identity, msal, authlib, pyopenssl, joserfc and google-auth all depend on it. The "Required transitive changes" section doesn't mention this platform im...
- Set PYTHONPATH to versioning/helper in tox env_run_base so uv sync --locked can build workspace editables with the custom build backend (needed after the uv 0.13.4 bump). - virtualenv 21.14.9 -> 21.14.13 (GHSA-cx6f-vjhg-g3cc) and certifi 2026.10.18 -> 2026.10.19 (PYSEC-2026-4320). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Krishnadheeraj (DheerajPannala)
left a comment
Krishnadheeraj (DheerajPannala)
left a comment
Contributor
There was a problem hiding this comment.
Your targeted upgrade approach and small, shared tox configuration adjustment keep this remediation focused and easy to audit.
One minor comment below.
Outside the changed lines:
- Minor: virtualenv is now the only lock entry from pypi.org, so setups that use only the internal feed can't use the committed lock (
uv.lock:6339). All 288 other registry entries in uv.lock come fromhttps://packagefeedproxy.microsoft.io/pypi/simple/, and so did virtualenv in the base lock. This change locksvirtualenv21.14.13 fromhttps://pypi.org/simple, with files.pythonhosted.org artifacts. When an index is configured, uv only trusts locked registry entries whose index is one of the configured ones. Otherwise it treats the lock as stale and re-resolves. That breaks contributors whose uv config uses the internal feed as the default index, which is where the rest of this lockfile comes from: - `uv sync --locked --all-extras --...
Since my last review:
- Still open: Avoid making the sandbox's glibc requirement mandatory (
uv.lock). The dependency remains mandatory for the default development environment: pyproject.toml:57 includes agent-framework, uv.lock:120-125 selects agent-framework-core[all], and uv.lock:295 includes Hyperl - Still open: New wheel-only hyperlight backend makes
uv syncfail on x86_64 Linux with glibc < 2.34 (uv.lock). This duplicates F921 and remains unresolved. uv.lock:400 still selects hyperlight-sandbox-backend-wasm for Linux x86_64 on Python <3.14, while uv.lock:2521-2526 provides only manylinux_2_34_x86_64 and - Still open: cryptography 50.0.0 entry drops the Intel-macOS and 32-bit Windows wheels, so those contributors now build from source (
uv.lock). uv.lock:1364-1417 still locks cryptography 50.0.0 without Intel-macOS or win32 wheels; its macOS wheels are arm64-only, and the sdist remains at line 1370. The unconditional azure-identity dependency
The internal feed now mirrors virtualenv 21.14.13, so lock it from the same index as every other entry instead of pypi.org. Same version and hashes; only the registry/URLs change. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
Krishnadheeraj (@DheerajPannala) thanks. On the virtualenv point: the internal feed now mirrors virtualenv 21.14.13, so 84c0a09 relocks it from |
Contributor
Author
|
Krishnadheeraj (@DheerajPannala) thanks, all three platform points are accurate. We're accepting them as trade-offs of the minimum patched versions rather than adding overrides or constraints:
Both affect only this repo's locked dev/CI environment ( |
Krishnadheeraj (DheerajPannala)
approved these changes
Oct 30, 2026
dbezic (dbezic)
approved these changes
Oct 30, 2026
Rick Brighenti (rbrighenti)
deleted the
users/rbrighenti-microsoft/python-minimal-vuln-fixes
branch
October 30, 2026 14:56
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
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.
Summary
Clears 92 of 93 open Dependabot alerts with a lockfile-only change (
uv.lock; nopyproject.tomledits). Each vulnerable package moves to its smallest patched version usinguv lock --upgrade-package <pkg>==<min patched>. Transitive packages move only when a patched version requires it, and then to the lowest compatible version.To keep the diff reviewable, entries for unchanged packages keep their original text. Newer uv versions add
size/upload-timemetadata to every entry, and that churn has been reverted. CI's uv 0.6.17uv lockaccepts the file unchanged.Supersedes #265 (setuptools).
Direct fixes (vulnerable package → minimum patched)
Required transitive changes (called out for review)
tooling-extensions-agentframeworkdepends on theagent-frameworkmeta package, which pullsagent-framework-claudeandagent-framework-mem0.claude-agent-sdk<0.1.49andmem0ai<2.agent-framework-claude 1.0.0b260609(needs core >=1.8.1) andagent-framework-mem0 1.0.0b260709(needs core >=1.11.0). Those are the versions used here, so 1.11.0 is the minimum core.[all]extra addsagent-framework-hyperlightand thehyperlight-sandbox*packages, and restrictspowerfx/pythonnet/clr-loaderto Python <3.14 (marker-only change).agent-framework-*sub-packages are unchanged.pyproject.toml[tool.tox.env_run_base]): addedset_env = { PYTHONPATH = "{tox_root}/versioning/helper" }. The uv 0.11 → 0.13 bump makesuv sync --lockedin tox rebuild the workspace editables, and tox stripsPYTHONPATH, so the custombuild_backendcouldn't be imported.Intentionally unchanged: wrapt stays <2 (2.x breaks the langchain tracer instrumentor), ruff stays 0.15.x, and microsoft-agents-*, openai-agents and a2a-sdk are untouched.
Platform impact (accepted trade-offs)
Both of these come directly from the minimum patched versions. They only affect this repo's locked dev/CI environment (
uv.lock). Published packages declare floors only, so downstream consumers already resolve the latest versions independently of this lock.agent-framework-mem0/agent-framework-claude(see above). Its[all]extra pulls inagent-framework-hyperlight→hyperlight-sandbox-backend-wasm 0.4.0. That package ships onlymanylinux_2_34_x86_64andwin_amd64wheels and no sdist. As a result,uv syncfails on x86_64 Linux hosts with glibc 2.28–2.33 (RHEL/Rocky/Alma 8, Debian 11 /*-bullseyeimages, Ubuntu 20.04) under Python <3.14. CI (ubuntu-latest), Windows x64, macOS and current Linux distros are unaffected.universal2/x86_64-macOS orwin32wheels for it. Contributors on those platforms build from the sdist, which needs a Rust toolchain and OpenSSL headers.Remaining alert (blocked)
google-adkcaps OpenTelemetry: the latest 1.x (1.39.1) at<=1.41.1, and even the latest 2.x (2.13.0) at<=1.44. This can't be cleared until google-adk relaxes its cap.Validation
uv sync --locked --all-extras --devon 3.11 and 3.12 ✅uv lockleaves the file byte-identical ✅tox -e verify-constraints,lint,format✅ (no external PYTHONPATH needed)pytest tests/ -m "not integration"): 859 passed, 3 skipped, 0 failed on both 3.11 and 3.12 (viatox -e py311,py312) ✅uv.lock: 92 cleared, 1 remaining (178).