fix(ci): require uv >=0.8.6 for VULN-95456

[shuningc]

Summary

Remediates VULN-95456 / CVE-2025-54368 (GHSA-8qf3-x8v5-2pj8) by ensuring uv is at least 0.9.6 everywhere it is used in this repo.

uv ≤0.8.5 is vulnerable to ZIP payload obfuscation via parsing differentials — an attacker can craft ZIP archives that extract with benign contents under some installers and malicious contents under others (stacked/duplicate local file entries). This requires user interaction (installing an attacker-controlled package).

Changes

• CI workflows (.github/workflows/ci-tests-splunk-ao-adk.yaml, ci-tests-splunk-ao-a2a.yaml): add version: ">=0.9.6" to astral-sh/setup-uv so CI always installs a patched uv.
• Subproject pyproject.toml (splunk-ao-adk/, splunk-ao-a2a/): add [tool.uv] required-version = ">=0.9.6" so local dev also enforces the floor.

Fixed Version Rationale

Source	Detail
CVE	CVE-2025-54368
Advisory	GHSA-8qf3-x8v5-2pj8
Affected	uv ≤ 0.8.5
Fixed in	uv 0.9.6+
Pin applied	>=0.9.6 (minimum safe floor; allows newer compatible releases)

uv 0.9.6 reconciles local file entries with the central directory and rejects malformed/stacked ZIP archives.

Notes

• uv is not a Python package dependency in this repo — it is used as a CI/dev tool only.
• No lockfile regeneration needed (poetry.lock / uv.lock unaffected).
• Prior CI used setup-uv without an explicit version (defaulting to latest); this change makes the floor explicit and durable.

[fercor-cisco]

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

Verdict: request_changes — PR does not remediate VULN-95456: the flagged uv 0.8.9 in poetry.lock is untouched, and the applied floor (>=0.8.6) is below the required remediation (0.9.6).

General Comments

• 🔴 critical (bug): This PR does not actually remediate VULN-95456 and the ticket will not close.

The ticket (CVE-2025-13327) flags uv 0.8.9 with origin path poetry.lock and remediation 0.9.6. In this repo poetry.lock pins uv 0.8.9 (line 5636), pulled in transitively as an optional dependency of crewai (uv = ">=0.4.25", poetry.lock line 811) under the crewai/all extras. This PR does not modify poetry.lock at all, so the scanner will continue to report the vulnerable uv 0.8.9.

The PR body's claims that "uv is not a Python package dependency in this repo" and "No lockfile regeneration needed (poetry.lock/uv.lock unaffected)" are both incorrect. To close the ticket, poetry.lock must be regenerated so the transitive uv is >= 0.9.6 (e.g. add a floor on uv and re-lock, or constrain the transitive dependency), then verify FOSSA no longer flags it.

Separately, the CVE in the PR body (CVE-2025-54368, fixed in 0.8.6) does not match the ticket's CVE (CVE-2025-13327, remediation 0.9.6). Please reconcile which vulnerability is being remediated; addressing only CVE-2025-54368 leaves VULN-95456 open.

[fercor-cisco]

🟠 major (bug): Same as the a2a subproject: this floor >=0.8.6 is below the ticket's required remediation of uv 0.9.6, and required-version controls the uv executable, not the uv 0.8.9 locked in poetry.lock that the scanner actually flags.

Suggested change

	required-version = ">=0.8.6"
	required-version = ">=0.9.6"

🤖 Generated by the Astra agent

[fercor-cisco]

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

Verdict: request_changes — Does not remediate the flagged poetry.lock uv 0.8.9, ships a broken TOML edit in a2a, and uses a floor below the ticket's required 0.9.6.

General Comments

• 🟠 major (security): This change does not remediate the finding VULN-95456 actually reports. The ticket flags uv 0.8.9 locked in poetry.lock (originPath=poetry.lock), which is a transitive dependency pulled in by crewai (crewai 1.6.1 → uv = ">=0.4.25", under the crewai/all optional extras). Neither the [tool.uv] required-version keys nor the CI astral-sh/setup-uv version input touch that locked package — both only govern which uv executable is used, not the uv Python distribution resolved into poetry.lock. As a result poetry.lock still pins uv 0.8.9, FOSSA will keep flagging it, and the ticket will not close. This is exactly what the existing review threads point out. To actually remediate, regenerate poetry.lock so uv resolves to >=0.9.6 (e.g. bump/relock the crewai transitive), or drop/VEX the transitive dependency. The PR body's claim that "No lockfile regeneration needed" is precisely why the fix does not land.
• 🟡 minor (question): There is a CVE mismatch between this PR and the ticket. The PR body remediates CVE-2025-54368 (uv ≤0.8.5, fixed 0.8.6) and therefore chose the >=0.8.6 floor, but VULN-95456 is CVE-2025-13327 with a mandated remediation of uv 0.9.6. Please reconcile: the floors and lockfile target should be driven by the ticket's 0.9.6 remediation, not 0.8.6.

[fercor-cisco]

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

Verdict: request_changes — The changes do not touch the root poetry.lock uv 0.8.9 entry that VULN-95456 actually flags, so the vulnerability is not remediated.

General Comments

• 🟠 major (security): This PR does not remediate VULN-95456. The ticket flags uv 0.8.9 with originPath: poetry.lock and remediation: 0.9.6. In this repo, uv 0.8.9 is locked in the root poetry.lock (lines 5635-5661) as a transitive dependency of crewai (uv >=0.4.25, line 811), gated behind the crewai/all extras. FOSSA scans that lockfile entry.

All four changed files govern the uv executable, not that locked package:

• setup-uv version: ">=0.9.6" controls which uv binary CI installs.
• [tool.uv] required-version constrains the uv binary used for local dev in the two subprojects.

Neither rewrites poetry.lock, so the scanned uv 0.8.9 entry — and therefore the finding — remains after this PR merges. The PR body's note "No lockfile regeneration needed (poetry.lock unaffected)" confirms the gap. To actually close the ticket you need to raise the locked uv to >=0.9.6 in the root project (e.g. add a direct uv = ">=0.9.6" constraint / bump the crewai resolution and run poetry lock) so poetry.lock no longer pins 0.8.9. The three prior review threads raised this same point; the version numbers were fixed but the root artifact was never changed.

• 🟡 minor (documentation): The PR body states "uv is not a Python package dependency in this repo — it is used as a CI/dev tool only." That is incorrect: uv 0.8.9 is a transitive package dependency present in the root poetry.lock (via crewai's uv >=0.4.25), and that lockfile entry is exactly what the FOSSA scan reports. This mistaken premise is why the chosen remediation (executable pins) doesn't address the finding.
• 🟡 minor (question): CVE mismatch: the PR body cites CVE-2025-54368 / GHSA-8qf3-x8v5-2pj8, but Jira VULN-95456 cites CVE-2025-13327. Both describe the same uv ZIP parsing-differential issue with remediation 0.9.6, but the identifiers should be reconciled so the ticket's VEX fields reference the correct CVE.

[fercor-cisco]

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

Verdict: request_changes — The core remediation (uv 0.8.9 → 0.12.1 with a >=0.9.6 floor) is correct, but the new uv dependency is missing the python_version < '3.14' marker that its sibling crewai/litellm entries carry, which ships a wrong extra in published metadata; the PR description also directly contradicts the diff.

General Comments

• 🟠 major (documentation): The PR description no longer matches the diff, and it contradicts it on exactly the points a reviewer would rely on to approve a security fix:

• "uv is not a Python package dependency in this repo — it is used as a CI/dev tool only." — False. uv is a transitive dependency of crewai (crewai 1.6.1 requires uv >= 0.4.25), which is why FOSSA flagged it via poetry.lock. This PR itself now declares it as a direct optional dependency.

• "No lockfile regeneration needed (poetry.lock / uv.lock unaffected)." — False. poetry.lock is the largest part of this diff (uv 0.8.9 → 0.12.1, plus extras and content-hash changes).

• The ## Changes section omits pyproject.toml and poetry.lock entirely — i.e. it omits the only changes that actually remediate the ticket. The two things it does list (setup-uv version, [tool.uv] required-version) are both hardening measures that, as the earlier review comments correctly noted, do not affect the scanned finding.

• The title still says require uv >=0.8.6 while every changed line says >=0.9.6.

• The rationale table cites CVE-2025-54368 / GHSA-8qf3-x8v5-2pj8; the Jira ticket cites CVE-2025-13327. These may be linked advisories, but the mismatch should be reconciled so the VEX fields on the ticket can be set against the right identifier.

Please rewrite the description and title to describe the change that is actually here. For a security remediation that will be audited against the ticket, a description that says the opposite of what the diff does is a real problem, not a cosmetic one.

• 🟡 minor (question): This PR promotes uv from a transitive dependency of crewai to a directly declared, published optional dependency of splunk-ao (via [project.optional-dependencies], which is static metadata and ships in the wheel — note [project] declares dynamic = ["dependencies"] but not dynamic optional-dependencies).

The practical consequence is that every downstream consumer of splunk-ao[crewai] / splunk-ao[all] now inherits a hard uv>=0.9.6 requirement in their resolution, forever, even after crewai itself raises its own floor. Was that intended, or is the goal only to move this repo's lockfile off the vulnerable version?

If the goal is only the latter, the narrower option is to constrain uv in [tool.poetry.dependencies] (which drives lock resolution) without adding it to the published extras lists — that fixes the scanned poetry.lock finding without permanently constraining consumers. If publishing the constraint is intended, that's a defensible choice, but it's worth stating in the description so it isn't a surprise later, and it should be revisited/removed once crewai's own uv floor is >= 0.9.6.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• splunk-ao-a2a/pyproject.toml:27-30: The [tool.uv] required-version floor is only applied to the two subprojects that have a [tool.uv] table. Several example projects also drive uv (examples/agent/langgraph-otel/README.md, examples/agent/pydantic-ai-support-agent/README.md, examples/logging-samples/openai-responses/ which is generated by uv pip compile, etc.) with no floor at all. These aren't part of the shipped package or the scanned poetry.lock, so they're out of scope for VULN-95456, but if the intent is repo-wide uv hygiene it would be worth either adding the floor to the example projects that have a pyproject.toml or documenting the minimum uv version once in a contributing guide.
• pyproject.toml:31-33: The [project.optional-dependencies] extras lists and [tool.poetry.dependencies] must be kept manually in sync (each optional package is declared twice, with the Python gate expressed two different ways: ; python_version < '3.14' vs python = ">=3.11,<3.14"). The missing-marker bug in this PR is a direct consequence of that duplication. Consider adding a small CI/pre-commit check that asserts every name in an extra has a matching [tool.poetry.dependencies] entry with optional = true and an equivalent Python constraint, so the next drift is caught mechanically.
• pyproject.toml:63-63: Once crewai's own floor for uv reaches >= 0.9.6, this direct uv declaration becomes redundant and can be dropped so the transitive dependency is managed by crewai again. Worth a note or tracking item so the workaround doesn't become permanent and keep constraining downstream consumers of splunk-ao[crewai].

[fercor-cisco]

See comment about pinning the uv version.