chore(deps): bump aiohttp to 3.14.3 and cryptography to 50.0.0 for security fixes - #361
Merged
Merged
Conversation
…curity fixes Resolves the four open Dependabot alerts on uv.lock: - aiohttp 3.14.1 -> 3.14.3 - GHSA-cq5v-8q36-5273 / CVE-2026-69244 (high): out-of-bounds heap read in the C HTTP response parser error path - GHSA-mfx4-hv73-q22v / CVE-2026-69243 (moderate): HTTP request smuggling via WebSocket upgrade - GHSA-mq44-7p77-q5h7 / CVE-2026-59881 (moderate): WebSocket client accepts compressed frames without negotiated permessage-deflate - cryptography 49.0.0 -> 50.0.0 - GHSA-g6cj-pr64-35w5 / CVE-2026-69247 (high): PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle Reachability triage: - cryptography is a direct runtime dependency, so every install gets the bump. The vulnerable PKCS#7 EnvelopedData decryption API is not called anywhere in this repo (usage is Ed25519 signatures, AES-GCM, Scrypt, and self-signed x509 generation for the win_agent channel), so exploitability here was low; bumped regardless. - aiohttp enters only through the optional service-mlx extra (mlx-vlm -> datasets -> fsspec[http] -> aiohttp); the base runtime never imports it. Lock moved to the fixed version for extra installs. python-xlib drops out of the lock because the current uv resolver (lock revision 3) prunes it as unreachable: it was only ever a Linux-only transitive of pywinauto, which this project uses on Windows. No resolved versions changed other than the two bumps. The large uv.lock diff is the lockfile format rewrite to revision 3 by uv 0.11; CI installs with pip (unaffected) and release.yml uses latest uv via setup-uv (supports revision 3). Co-Authored-By: Claude Fable 5 <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
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
Resolves all four open Dependabot alerts on
uv.lock(2 high, 2 moderate):Reachability triage
cryptography>=42.0), so every install is exposed to the vulnerable version range. The vulnerable PKCS#7EnvelopedDatadecryption API is not called anywhere in this repo — usage is Ed25519 sign/verify (qualification, eligibility artifacts), AES-GCM + Scrypt (openadapt_flow/crypto.py), and self-signed x509 generation (win_agent/tls.py) — so practical exploitability here was low. Bumped regardless.service-mlxextra:mlx-vlm → datasets → fsspec[http] → aiohttp. Installs of the base package never pull it; the lock now resolves the fixed version for extra installs.Lockfile notes
uv.lockdiff is uv 0.11 rewriting the lock to formatrevision = 3. Resolved-version changes are exactly the two bumps above plus python-xlib removed — the current resolver prunes it as unreachable (it was a Linux-only transitive of pywinauto, which this project uses on Windows only). Verified by structured old-vs-new lock comparison.ci.ymluntouched (SHA-pinned inpublic-artifacts.json); CI jobs install with pip and do not consume the lock.release.ymluses latest uv viasetup-uv, which supports lock revision 3.scripts/check_release_consistency.pypasses: version 1.31.0 synchronized across project, module, and lock.Test plan
uv sync --extra devclean with the new lockpytest -k "crypto or tls or qualification or artifact or eligibility"— 562 passed, 6 skipped🤖 Generated with Claude Code