fix(deps): require aiohttp >=3.14.1 for VULN-88795

[shuningc]

Summary

Fixes VULN-88795 by upgrading transitive aiohttp to ≥3.14.1 (lock resolves 3.14.2).

aiohttp ≤3.14.0 allows a TLS SNI server_hostname bypass on reused connections (fixed in 3.14.1).

Approach

aiohttp remains transitive — no direct aiohttp floor in pyproject.toml.

An initial commit added a direct aiohttp constraint; that was reverted in 8025a47 in favor of a lock-only bump. This matches how aiohttp is consumed (via galileo-core / optional extras), without adding a new top-level dependency.

Branch rebased onto latest main (c4ef2f4); poetry.lock regenerated with Poetry 2.4.1.

Changes

Area	Change
poetry.lock	aiohttp 3.13.5 → 3.14.2
pyproject.toml	vcrpy ^7 → ^8.3.0 (required for aiohttp 3.14 compatibility)
poetry.lock (collateral)	vcrpy 7 → 8.3.0; drop stale types-requests / types-urllib3 stubs; remove PyPy-only urllib3 1.26.20 lock entry (CPython path uses urllib3 2.5.0)
Examples	minimal-agent-example + startup-simulator-3000 → aiohttp==3.14.2
FSI example lock	Regenerated → aiohttp 3.14.2 (+ Poetry/ruff lock churn)

urllib3 note

This PR does not intentionally upgrade urllib3 for CPython — 2.5.0 was already in the lock. Lock regeneration removed the separate 1.26.20 entry selected only under platform_python_implementation == "PyPy". Full urllib3 2.7.0 remediation is tracked in VULN-88814.

Vulnerability

• Ticket: VULN-88795
• Package: aiohttp
• Fixed in: 3.14.1+

Test plan

• CI passes (vcrpy 8 + aiohttp 3.14)
• pip install aiohttp==3.14.2 pulls yarl / multidict / propcache (startup-simulator smoke)
• Example pins aligned to lock-resolved 3.14.2 (no 3.14.1 drift)

[fercor-cisco]

Key problems

[Major] Description ≠ diff. The title/summary claim a direct floor aiohttp = ">=3.14.1,<4" was added "following the idna/filelock convention." Neither is
true — pyproject.toml has no aiohttp entry (grep → 0), and no idna/filelock floors exist. The commit history shows this: cda63c0 added a direct requirement, then 8025a47 reverted to "keep aiohttp transitive, bump lock only." The description still describes the abandoned approach.

[Major] "Only aiohttp changed" is false. The lock also bumps urllib3 1.26.20 → 2.5.0 (a major version jump), bumps vcrpy 7 → 8.3.0, and drops types-requests/types-urllib3. The urllib3 2.x transition shouldn't be hidden behind an "only aiohttp" claim — it should be a conscious decision.

[Minor] Version drift: locks say 3.14.2, example requirements.txt files pin 3.14.1. Both safe, but avoidable inconsistency.

[Minor] startup-simulator-3000/requirements.txt bumps aiohttp but carries none of aiohttp 3.14's supporting deps (yarl/multidict/propcache) — worth a pipinstall -r smoke test.

The changes needed are accuracy and consistency, not code logic. The vcrpy bump is legitimate and necessary. Fix the title/description to match the transitive approach, confirm the urllib3 major bump is intentional, and reconcile the pin mismatch.

[shuningc]

Key problems

[Major] Description ≠ diff. The title/summary claim a direct floor aiohttp = ">=3.14.1,<4" was added "following the idna/filelock convention." Neither is true — pyproject.toml has no aiohttp entry (grep → 0), and no idna/filelock floors exist. The commit history shows this: cda63c0 added a direct requirement, then 8025a47 reverted to "keep aiohttp transitive, bump lock only." The description still describes the abandoned approach.

[Major] "Only aiohttp changed" is false. The lock also bumps urllib3 1.26.20 → 2.5.0 (a major version jump), bumps vcrpy 7 → 8.3.0, and drops types-requests/types-urllib3. The urllib3 2.x transition shouldn't be hidden behind an "only aiohttp" claim — it should be a conscious decision.

[Minor] Version drift: locks say 3.14.2, example requirements.txt files pin 3.14.1. Both safe, but avoidable inconsistency.

[Minor] startup-simulator-3000/requirements.txt bumps aiohttp but carries none of aiohttp 3.14's supporting deps (yarl/multidict/propcache) — worth a pipinstall -r smoke test.

The changes needed are accuracy and consistency, not code logic. The vcrpy bump is legitimate and necessary. Fix the title/description to match the transitive approach, confirm the urllib3 major bump is intentional, and reconcile the pin mismatch.

Dealt with the comments.

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — Lock regeneration downgrades urllib3 2.7.0→2.5.0 (reintroduces VULN-88814/CVE-2026-21441) plus cryptography, pillow, protobuf, click, python-multipart; an example's install is also broken.

General Comments

• 🔴 critical (security): poetry.lock downgrades urllib3 from 2.7.0 → 2.5.0 (see diff around the urllib3 stanza: the merge base had a non-PyPy version = "2.7.0" entry, HEAD collapses to a single version = "2.5.0"). urllib3 is a core dependency (optional = false, groups main/test), so this is not behind an extra. Downgrading to 2.5.0 reintroduces CVE-2026-21441 — the decompression-bomb issue on redirect responses — which is exactly VULN-88814 (remediation ≥2.6.3/2.7.0). This PR is a security fix that simultaneously regresses another security fix that main had already applied.

The PR description states "This PR does not intentionally upgrade urllib3 for CPython — 2.5.0 was already in the lock." That is contradicted by the diff: the base had 2.7.0 for CPython. Please regenerate the lock from current main so urllib3 stays at ≥2.7.0 (or explicitly pin urllib3 = ">=2.7.0" / >=2.6.3). This must be resolved before merge — otherwise merging closes VULN-88795 while reopening VULN-88814.

• 🟠 major (security): The lock regeneration produced broad, unexplained downgrades well beyond aiohttp/vcrpy: cryptography 49.0.0 → 45.0.6, pillow 12.3.0 → 11.3.0, protobuf 6.33.6 → 6.31.1, click 8.4.2 → 8.1.8, python-multipart 0.0.32 → 0.0.20, and cffi 2.x removed in favor of 1.17.1. Several of these (pillow, cryptography, python-multipart) are security-sensitive packages where downgrading can reopen fixed CVEs. This pattern strongly suggests the lock was regenerated in an environment divergent from current main (different index state / resolver inputs) rather than a clean rebase. Please regenerate poetry.lock from an up-to-date main checkout and confirm the diff contains only the intended aiohttp (+vcrpy) changes; the downgrade churn should disappear. As-is, the claim that only aiohttp/vcrpy changed is inaccurate and the collateral downgrades are a merge risk.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• examples/agent/startup-simulator-3000/requirements.txt:3-57: aiohttp is listed twice (line 3 pinned ==3.14.2 and line 57 bare aiohttp). Deduplicate to a single pinned entry to avoid confusion in the requirements file.

[fercor-cisco]

🟠 major (bug): aiohttp is bumped to 3.14.2, but its supporting deps in this file are left below aiohttp 3.14.2's declared floors: aiohttp 3.14.2 requires aiohappyeyeballs>=2.5.0 (pinned here to 2.4.6) and aiosignal>=1.4.0 (pinned here to 1.3.2). pip install -r requirements.txt will hit a ResolutionImpossible / produce a broken environment. The PR test plan only smoke-tested startup-simulator-3000 (which doesn't pin these two), so this file was not exercised. Bump aiohappyeyeballs>=2.5.0 and aiosignal>=1.4.0 (e.g. 2.6.1 / 1.4.0) to match aiohttp 3.14.2.

Suggested change

	aiohappyeyeballs==2.4.6
	aiohttp==3.11.12
	aiohttp==3.14.2
	aiosignal==1.3.2
	aiohappyeyeballs==2.6.1
	aiohttp==3.14.2
	aiosignal==1.4.0

🤖 Generated by the Astra agent

[fercor-cisco]

examples/agent/minimal-agent-example/requirements.txt:18-18 (line not in diff)

🟡 minor (other): This example pins urllib3==2.6.3 (which does carry the VULN-88814 fix), yet the library's own poetry.lock in this same PR pins urllib3 2.5.0. The examples are now ahead of the shipped lock on the security fix — an avoidable inconsistency. Once the lock is regenerated to keep urllib3 ≥2.7.0, align these pins (or bump the example to 2.7.0).

🤖 Generated by the Astra agent