fix(ci): un-stale the apt layer behind the GHA cache + ignore gh os.Root CVE#143
Merged
Conversation
… CVE Every branch went CI-red on 2026-07-13 when Debian shipped curl 8.14.1-2+deb13u4 (CVE-2026-5773, CVE-2026-6276): the dockerfile's 'apt-get upgrade -y' only patches at layer-build time, and the GHA layer cache (cache-from: type=gha) kept serving the stale apt layer, so the fix never entered the image. New refresh layer sits below the source COPY — busts on every commit, catches security patches without un-caching the expensive layers above. Also adds CVE-2026-39822 (Go stdlib os.Root symlink following, via /usr/bin/gh built on Go 1.26.4) to .trivyignore with rationale, same family as the eight gh Go-stdlib ignores already documented there. Merge this first, then update the red branches from main — same unblock shape as PR #130 (June starlette CVEs). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
spashii
added a commit
that referenced
this pull request
Jul 14, 2026
…ates real (#145) ## The finding 30 days of audit logs: **Exa's API never failed once (8/8 calls healthy). Every "exa breaks" incident was agent-side**, in two modes: 1. **Session-killing tool hallucination (3 crashes).** The skill catalog advertises `exa-search` in every system prompt, but no `exa_search` tool was registered — Flash pattern-matched the name and emitted `exa_search(...)` calls the ADK runner had no handler for → unhandled exception → whole session dies with exit 1, no reply to the user (Jul 9 ×2, Jul 13 ×1 — the last one misdiagnosed itself to Cesare as a "document retrieval parsing error"). Sam journaled the root cause on Jul 9 and re-hit it Jul 13: prose can't patch a model prior. 2. **jq-eaten results (2 occurrences).** The skill's only curl template piped to `jq`, which isn't installed in the container — searches succeeded, got billed, output vanished. ## The fix - **`exa_search` FunctionTool** in `adk_runner.py` with the exact name + `query` arg Flash already tries to call. httpx (existing dep), results formatted in Python (no shell parsing), Exa error tags surfaced as strings (429/400/402 branchable), empty results phrased as guidance not failure, per-query cost reported. Registered in `worker_tools` (→ main, worker, pro_executor) and the `parallel_workers` fanout; mentor stays read-only. - **Skill rewritten** to what prose is for: when/when-not (native tool first), cost discipline, and a jq-banned curl fallback for advanced params — corrected against the 2026-07 Exa API docs (current `type` enum, conditional response fields, category conflicts). ## Verification - 5 new tests (signature pin, missing-key error, never-raises-on-connect-failure, FunctionTool wrap, both registration sites); full suite **310 passed**; ruff + ruff-S clean. - **Live-verified** against the real API (~$0.02): happy path with cost line, `include_domains`, and invalid key → `error: Exa HTTP 401 [INVALID_API_KEY]` as a string. - Post-merge check (1 week): the crash signature (`exa_search` call → session errored) should be extinct in `tool_calls/*.jsonl`, and no bash entry should contain `api.exa.ai … | jq`. Diagnosis produced by a 4-agent research workflow during the 2026-07-14 maintenance follow-up; full write-up available on request. Tier 3 (runtime). Note: CI will stay red until #143 (trivy/apt-cache fix) merges — same as the rest of the queue. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: sam-dembrane <sam-dembrane@sam2ks-MacBook-Pro.local> 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
1 participant
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.
What broke
Every PR branch went CI-red yesterday (#138–#142 all fail the trivy step; the older green PRs just ran their checks before the CVEs published). Two causes:
deb13u4) but the image stays ondeb13u3:apt-get upgrade -yonly runs at layer-build time, andcache-from: type=ghakeeps serving the cached apt layer. The dockerfile's own comment history (gh CVE-2026-48501) shows this trap has bitten before.os.Rootsymlink following inside/usr/bin/gh(built with Go 1.26.4, fixed in 1.26.5). Same family as the eight gh Go-stdlib CVEs already in.trivyignore; Sam runs gh against repos it cloned itself, not attacker-controlled trees.The fix
USER root → apt-get update && upgrade → USER samlayer below the source COPY, so it busts on every commit build and picks up security patches, while the expensive layers above stay cached. Known edge documented in the comment: re-running CI on a bit-identical branch still hits the cache; merging main forces the refresh.CVE-2026-39822added to the gh block in.trivyignorewith rationale.Merge order
Merge this first, then update the red branches from main (#138, #139, #140, #141, #142) — same unblock shape as June's #130.
Found during the 2026-07-14 follow-up to the monthly maintenance pass.
🤖 Generated with Claude Code