fix(deps): raise current security floors

[vexclawx31]

Summary

Refresh the dependency-floor change on current main and enforce the reviewed versions across every affected install path:

• cryptography==48.0.1 as an audited exact core pin for GHSA-537c-gmf6-5ccf
• starlette==1.3.1 across dev, MCP, computer-use, web, and both lazy-install surfaces
• python-multipart==0.0.32 across the core dependency, web extra, and dashboard lazy-install surface
• uv.lock regenerated from current main

This also extends the existing invariant-style metadata coverage so the reviewed core exact pins and security-critical lazy paths cannot silently drift.

Resolver note

cryptography==48.0.1 cannot coexist with alibabacloud-tea-openapi==0.4.4, which declares cryptography>=3,<47. The current resolver therefore selects the compatible newer alibabacloud-tea-openapi==0.4.5, updates darabonba-core to 1.0.8, and adds its websocket-client==1.9.0 dependency. This is required resolver movement rather than incidental lock churn; no packages are downgraded or removed.

Focused validation covers that path: the locked Dingtalk extra installs cleanly, uv pip check passes, both dingtalk_stream and the Dingtalk card SDK import successfully, and the Dingtalk auth/gateway suites pass.

Overlap review

The closest live overlaps were rechecked before refresh:

• fix(update): refresh cve dependency pins #60839 synchronizes the same three CVE pins and lazy paths, but does not raise the core python-multipart declaration that the live review requested here. Its cryptography 49.0.0 choice also lacks Intel-macOS and 32-bit-Windows wheels; this PR uses the advisory-fixed 48.0.1 exact pin, which retains those supported-platform wheels.
• fix(deps): resolve high-severity runtime advisories #65345 raises the core multipart floor but is currently conflicting and does not represent the same current-main replay.
• fix(deps): raise vulnerable dependency floors #68648 and Bump 10 PyPI packages to fix known vulnerabilities #71777 are broader dependency refreshes with different package scope/policy.

This PR stays focused on the reviewed cryptography/Starlette/multipart contract instead of absorbing unrelated dependency bumps.

Verification

• TDD: focused metadata tests first failed on the stale Starlette, cryptography, multipart, and lock versions, then passed after the synchronized update.
• Targeted tests: 235 passed, 1 skipped across packaging/project metadata, lazy-dependency behavior/durable targets, computer-use lazy install, dashboard file/multipart APIs, security audit, and Dingtalk auth/gateway paths.
• Canonical per-file runner across the full relevant files: 454 passed; one unrelated computer-use default-window test failed identically on untouched origin/main.
• Broad web/dashboard compatibility slice: 1,218 passed, 2 skipped; three known order-dependent auth tests failed in the combined process but each passed when rerun in isolation. Four profile-environment-contaminated failures were reproduced on untouched main and passed after sanitizing the inherited dashboard auth/public-URL env.
• uv lock --check
• uv pip check — 102 installed packages compatible
• ruff check . — passed (one pre-existing invalid-noqa warning)
• git diff --check
• Installed versions: cryptography 48.0.1, python-multipart 0.0.32, Starlette 1.3.1
• Cross-platform artifact check: cryptography 48.0.1 publishes universal Intel/Apple-Silicon macOS, 32/64-bit Windows, and Linux x86_64/aarch64 wheels; the independent review's cryptography 49.0.0 platform blocker is resolved.
• Independent exact-commit re-review: SHIP — no blockers. The follow-up review confirmed the new dashboard test uses the public feature_specs() API and introduces no source/AST inspection.
• Hermes OSV audit: 102 components scanned; 0 findings for cryptography, Starlette, python-multipart, alibabacloud-tea-openapi, alibabacloud-dingtalk, darabonba-core, or websocket-client. Unrelated existing findings remain outside this focused PR.

Scope

No merge, deployment, gateway restart, or live-profile/runtime change is part of this PR.

[alt-glitch]

This was generated by AI during triage.

Related: part of the June/July-2026 dependency-CVE floor-bump cluster of competing/overlapping consolidated PRs — #63099, #56830, #58487, #59993, #54424, #51305, tracking #47998. All bump the same advisory floors (cryptography GHSA-537c-gmf6-5ccf, Starlette 2026 set, python-multipart parsing/smuggling). A human should pick the canonical consolidated bump; these are related, not duplicates of each other.

[teknium1]

Thanks for consolidating the dependency-floor updates. The security premise is still present on current main, but the patch does not yet cover every dashboard install path.

Problems

• tools/lazy_deps.py:219-225 still pins the tool.dashboard lazy-install path to starlette==1.0.1 and python-multipart==0.0.27. hermes_cli/web_server.py:104-110 invokes that bundle after an import failure, so a lean dashboard install bypasses the proposed [web] floors.
• pyproject.toml:112-116 retains core python-multipart>=0.0.9,<1; changing only the [web] copy does not enforce the proposed floor for that declared core dependency.
• The changed cryptography spec replaces the exact core pin despite the exact-pin policy in pyproject.toml:25-37.

Suggested changes

• Update the dashboard lazy bundle and the core multipart declaration in lockstep, then regenerate uv.lock.
• Keep cryptography at an audited exact version; the candidate lock resolves 49.0.0.

This is an automated hermes-sweeper review.

[teknium1]

This is a core direct dependency, while pyproject.toml:25-37 requires exact pins so upgrades are intentional and reviewed. Please retain an audited exact pin (the candidate lock resolves 49.0.0) instead of reopening this range.

[teknium1]

Please update the corresponding tool.dashboard bundle in tools/lazy_deps.py:219-225. hermes_cli/web_server.py:104-110 invokes it for lean installs, and it still installs Starlette 1.0.1 and python-multipart 0.0.27.

[egilewski]

not enough evidence

I could not complete a reliable security review because the run-owned deterministic patch replay of PR head cde8e68b4cb5798efeeff00bcd10ee135154ecdd onto current GitHub main at 8208fc52701332f213e6c51ebc0b610be00300de failed with patch_replay_conflict, and no run-owned local rebase or patch replay produced a coherent integrated tree to evaluate. The submitted branch was stale or conflicted, but that status was treated only as setup context and not as a standalone security finding or review blocker. Please resolve or rebase the conflicts so the security review can be rerun against a coherent tree.

Review setup: A run-owned local rebase or patch replay was attempted against current GitHub main; it did not produce a coherent review tree, and this does not imply that the submitted branch merges cleanly.

Signed: GPT-5.6-sol-xhigh in Codex

[vexclawx31]

@egilewski The branch has been replayed coherently onto current main and the earlier security-review gaps are addressed on refreshed head 6a0260e11a0ddc5d18447c691c220585c3eab37c:

• exact audited cryptography==48.0.1 (the GHSA-fixed release that retains Intel-macOS and 32-bit-Windows wheels)
• core + web + dashboard-lazy python-multipart==0.0.32
• dev/MCP/computer-use/web/dashboard-lazy starlette==1.3.1
• updated invariant coverage, computer-use contract, and regenerated uv.lock

The Alibaba lock movement is required: alibabacloud-tea-openapi==0.4.4 caps cryptography below 47, so uv resolves the compatible newer 0.4.5 release plus its current transitive dependencies. The Dingtalk extra installs cleanly, relevant SDK objects instantiate, its focused suites pass, and uv pip check is green.

Local verification: 235 targeted tests passed (1 skipped); the broad web/dashboard slice passed 1,218 tests (2 skipped), with three known order-dependent tests passing individually; uv lock --check, Ruff, diff check, package compatibility, and targeted OSV checks passed.

Could you please rerun the security review against this refreshed head? No merge or runtime rollout is requested.

[vexclawx31]

CI follow-up on 6a0260e11a0ddc5d18447c691c220585c3eab37c:

• 25 checks passed, including all Python test slices, e2e, Ruff/ty, uv lock, OSV, supply-chain, dependency upper bounds, and both amd64/arm64 Docker builds.
• The sole direct failure is Python lints / Windows footguns (blocking) on scripts/tool_search_livetest2.py:190 (Path.write_text() without an encoding). That path is unchanged by this PR (git diff --quiet origin/main...HEAD -- scripts/tool_search_livetest2.py returns clean), and the same checker failure reproduces locally on untouched origin/main.
• All required checks pass fails only as the aggregate consequence of that base-branch footgun.

I am leaving the unrelated base file out of this focused security dependency PR rather than adding churn. No merge or runtime rollout was attempted.

[egilewski]

suggesting changes

The base installation still has no direct Starlette security floor. fastapi>=0.104.0,<1 permits the already-installed Starlette 1.0.1, and hermes_cli.web_server only invokes tool.dashboard lazy repair after an import failure, so a normal update can keep the vulnerable parser. Please add starlette==1.3.1 to the core requirements and cover this base-update path with a regression test.

Security evidence:

• trust boundary: Unauthenticated dashboard request bodies reach Starlette's form parser through the core FastAPI/web-server path.
• source/sink/invariant: Every base install and update must constrain Starlette to 1.3.1 before hermes_cli.web_server accepts requests, independently of optional extras.
• current-main reproduction: Current main locks FastAPI 0.133.1 with Starlette 1.0.1, and the exact-version request probe accepts two urlencoded fields despite max_fields=1.
• PR-head or patch-replay validation: This head pins Starlette only in optional extras and lazy-install entries; FastAPI 0.133.1 still declares only starlette>=0.40.0, which accepts Starlette 1.0.1, and the dashboard import guard succeeds with that combination without calling lazy repair.
• positive/negative cases: The reviewed Starlette 1.3.1 target rejects the excess field, while the base-compatible FastAPI 0.133.1 plus Starlette 1.0.1 combination imports successfully and retains the vulnerable behavior.
• residual bypass search: _verify_core_dependencies_installed checks only packages directly listed in [project.dependencies], and the new core security-floor test does not include Starlette, leaving no base-path enforcement for this floor.
• reviewer validation: Package metadata confirms FastAPI's starlette>=0.40.0 constraint accepts 1.0.1, and an invocation-level import probe reached starlette.concurrency.run_in_threadpool successfully with those exact versions.

Signed: GPT-5.6-sol-xhigh in Codex

[teknium1]

Resolved by #72362 (merged) — same floors this PR raised: cryptography 48.0.1, starlette 1.3.1, python-multipart 0.0.32, across pyproject + LAZY_DEPS + uv.lock with a CI anti-downgrade guard. #60839 by @embwl0x was the earliest open submission of the refresh so it got the salvage. Thanks @vexclawx31.