Sanitize published dashboard DB: full runs table (agent free-text + repo/issue refs) is exposed to a public bucket with no redaction or per-repo gating

[labro-bot]

This is an autonomous proactive suggestion requested by Labro.
Perspective: privacy-steward

Trace what data this system collects, stores, logs, and transmits. What is
retained longer than needed, logged that shouldn't be, or exposed wider than
necessary? Propose the most important data-handling fix.

---

Agent findings will be posted as a comment below.

Agent: codex
Model codex failed: turn.failed. Trying fallback with claude-code:claude-opus-4-8.

[labro-bot]

Privacy-steward review: what Labro collects, stores, and publishes

I traced the data path from run → SQLite → publish-db → public R2 bucket. The store itself is reasonable (structured fields, no raw agent stdout/stderr or secrets persisted — subprocess output in _subprocess.py is parsed then discarded, and /data/labro.log stays on the host). The exposure is on the publish side.

1. (Highest) The full runs DB is published to a world-readable bucket with zero sanitization

labro publish-db (cli.py:_cmd_publish_db) runs VACUUM INTO over the entire labro.db and uploads the raw snapshot to R2 (r2.upload_snapshot), served publicly at labro.rossarnold.uk and loaded whole into the browser by the SPA (sql.js). No column is dropped, no row is filtered, nothing is redacted. That means every row of runs and items_touched is public, including agent-generated free text:

• runs.summary, runs.actions_taken, runs.failure_reason — written by the agent; can echo issue/PR body text, code snippets, file paths, internal URLs, and (in failure tracebacks) anything that leaked into the agent's output.
• runs.task_description, runs.source_description, runs.item_url, items_touched.repo / item_number — enumerate every repo, issue, and PR Labro has ever touched.

This is safe only under an implicit, unenforced assumption: that every target repo is public and no agent summary ever contains a sensitive string. There is no per-project publish gate — DashboardConfig has only a global enabled, and ProjectConfig has no private/publish flag (config/schema.py). The config repo labro-rssrn is already private; the moment Labro is pointed at any private repo, the dashboard silently exfiltrates private repo names, issue titles, and agent summaries of private content to a public URL.

Proposed fix (the single most important data-handling change): sanitize the snapshot before upload instead of VACUUM INTO of the raw DB. Two layers:

• Column allowlist — build the snapshot by SELECTing only the columns the dashboard renders into a fresh schema; drop free-text fields the SPA doesn't need (candidates: actions_taken, failure_reason, source_description, task_description).
• Per-repo publish gate — a project.private = true (or dashboard.publish = false) flag that excludes private-repo runs from the snapshot, or includes them as counts/metrics only with free-text columns nulled. Resolution stays in the documented order (label rule → task source → project → defaults).

2. Published snapshots are immutable-cached for a year and never pruned — a leak is permanent and un-revocable

r2.upload_snapshot sets Cache-Control: public, max-age=31536000, immutable, keys are content-addressed, and dashboard-publish.yml uploads with --no-delete. Every historical snapshot object therefore lives in the public bucket indefinitely, with CDN copies cached up to a year. If sensitive data is ever published once, rotating manifest.json does not help — the old hashed .db object is still directly fetchable by URL. There is no R2 lifecycle rule and no cleanup of superseded snapshots.

Fix: add an R2 lifecycle/expiry rule (or an explicit prune of stale db/ objects in publish-db, keeping only the current manifest target), and reconsider the 1-year immutable cache so a bad publish can actually be flushed.

3. runs free-text is retained indefinitely and re-published in full every cycle

There is no retention policy on the runs table; rows and their agent summaries accumulate forever and are re-uploaded in full on every publish-db. A dashboard showing activity/cost trends needs recent detail plus aggregates, not unbounded free-text history.

Fix: a configurable retention window that nulls the free-text columns (or deletes rows) beyond N days while keeping the numeric metric columns the trend charts rely on.

---

Recommendation: #1 is the priority and the clearest single fix. I've held off opening a PR because the right shape (column allowlist vs. per-project private flag, and which columns the SPA actually renders) is a design call for the maintainer — happy to implement whichever direction you prefer. #2 is a low-effort, high-value follow-up (lifecycle rule); #3 is optional hardening.

[labro-bot]

Labro's agent (claude-code) investigated this suggestion but reported failure.

Reason: error_max_turns

[rssrn]

Triage — scope decided

Reviewed against the actual publish path (cli._cmd_publish_db → VACUUM INTO → raw upload to public R2) and the current config. Reframing the problem, then narrowing scope.

Key context: all currently-managed repos (labro, newschart, birdbird) are public. So the metadata this exposes — repo names, issue/PR numbers, item_url — is already world-readable on GitHub; publishing it adds no net exposure today. The one genuinely new surface is agent free-text (summary/actions_taken/failure_reason), but that text describes public issues in public repos. In other words, the "silent exfiltration of private content" scenario cannot occur under the current config — there is no private content.

The real problem is not missing redaction, it's a missing safety primitive: the design is only safe under the unenforced, invisible assumption that every target repo is public. The day a private repo is added to labro.toml, its name, issue titles, and agent summaries ship to a public URL with no warning. That latent trap is the thing worth fixing.

Scope we're taking forward — per-project publish gate (opt-in)

Add a per-project publish flag, defaulting to don't-publish, so publishing is always an explicit, deliberate decision:

• New field on ProjectConfig (e.g. publish: bool = False).
• publish-db filters the snapshot to include only opted-in projects' runs / items_touched rows before VACUUM INTO.
• Fails safe: a new project (or a new Labro user) publishes nothing until they explicitly turn it on. Existing published projects get publish = true set explicitly in config.

Row-level exclusion (not column-level redaction) is deliberate: a non-published project contributes nothing, so there's no per-column "did I catch every leaky field?" audit burden.

Considered and deliberately not doing

• Secret-pattern scrub on free-text before upload — defends only against a traceback accidentally echoing an env secret. Low probability (_subprocess.py parses then discards raw output), and orthogonal to the privacy problem. Not worth it.
• Column-level redaction via the reserved DashboardConfig.redact flag — only matters for a "public metrics, private prose" deployment, which nobody is asking for. Leaving redact as the reserved no-op it is today; the publish gate composes with it later if that need ever appears.

Net: this ticket becomes "add an opt-in per-project publish gate to the dashboard snapshot", nothing more.

[labro-bot]

Labro picking up, selected based on #ai-analyst label. Assigning to opencode:opencode/big-pickle.
Model opencode:opencode/big-pickle failed: opencode structured output invalid: structured_output.outcome must be one of ['failure', 'partial', 'success'], got None. Trying fallback with opencode:opencode/deepseek-v4-flash-free.

[labro-bot]

Technical analysis — per-project publish gate

Summary

The publish-db command snapshots the entire labro.db via VACUUM INTO and uploads it to a public R2 bucket. Every row in runs and items_touched is exposed regardless of which project it belongs to. The fix is to add a publish: bool = False field to ProjectConfig and filter the snapshot to only include rows from opted-in projects before upload. New deployments and new projects publish nothing until explicitly enabled.

Risks & concerns

• Dashboard SPA breakage if filtering is done post-VACUUM INTO. The SPA (sql.js) loads the .db file directly and queries its tables. If we remove rows after snapshotting, the snapshot is already a copy of the full DB — that works fine. If we instead build a filtered snapshot via SELECT … INTO or ATTACH, we need to ensure the resulting DB has the same schema (indexes, projects table) the SPA depends on. Row-level filtering via a fresh ATTACH'd snapshot is cleanest.

• items_touched join to runs for project filtering. items_touched has no project column — it links via run_id. A filtered publish query must JOIN items_touched ON runs.run_id = items_touched.run_id and filter both tables by runs.project IN (…). This is straightforward but must not be missed.

• The projects metadata table is always upserted before snapshotting (cli.py:1207-1208). After filtering, the projects table in the snapshot should only list published projects — otherwise the SPA's project filter dropdown shows projects with zero runs, which is confusing but not a data leak. Worth aligning.

• No migration needed. publish = False is the Pydantic default on ProjectConfig. Existing projects in labro.toml without the field silently get False, which is the desired safe-by-default behavior. The three current public projects (labro, newschart, birdbird) will need publish = true added to their config — a one-line TOML edit.

• VACUUM INTO cannot operate on an in-memory or ATTACH'd database. The filtered snapshot must be written to a real file. The cleanest approach: open the source DB, ATTACH a fresh temp DB, INSERT INTO snapshot.runs SELECT … FROM main.runs WHERE project IN (…), then VACUUM INTO the attached DB. Alternatively, copy the schema DDL into a new file and INSERT the filtered rows — same effect.

• Existing immutable-cached snapshots. Old snapshots in the public bucket that contain all projects will remain fetchable by content hash. The lifecycle/pruning issue (Sanitize published dashboard DB: full runs table (agent free-text + repo/issue refs) is exposed to a public bucket with no redaction or per-repo gating #51 comment Test 2 #2) is separate and out of scope here, but worth noting that the gate only affects future publishes.

Open questions

• Column allowlist: do we also want it, or only the row gate? The maintainer's triage says "row-level exclusion, not column-level redaction." The SPA renders summary, actions_taken, failure_reason, task_description, and source_description in the RunDrawer — all agent free-text fields. For public repos this is fine today. If column allowlist is ever needed later, the DashboardConfig.redact reserved flag is the planned hook. Agreeing to leave this as a separate future concern.

• source_description column scope. The gh-dependabot-alert source writes source_description which can include alert metadata (package name, severity, GHSA ID). This is public info from the GitHub API, not sensitive, but worth confirming that's acceptable for all future task sources.

Recommended approach

Implement as described in the triage — per-project publish flag, row-level filtering. The change is well-scoped and mechanical:

1. ProjectConfig: add publish: bool = False (schema.py:297).
2. _cmd_publish_db: after loading config, collect published = [p.name for p in config.projects if p.publish]. Replace the VACUUM INTO approach with: ATTACH a fresh temp DB, copy schema + filtered runs/items_touched/projects rows, then VACUUM INTO the attached DB. This keeps the snapshot file self-contained.
3. Config update: add publish = true to the three current projects in labro.toml.
4. Tests: cover (a) no projects published → empty snapshot, (b) mixed publish flags → only opted-in projects' rows, (c) items_touched filtered correctly via JOIN.

This is a ~50-line change across 2-3 files plus config. No spike needed. Recommend implementing directly.

[labro-bot]

Analysis — per-project publish gate

Summary: Add publish: bool = False to ProjectConfig and filter the dashboard snapshot to include only rows belonging to opted-in projects. Default-off means a new project silently contributes nothing to the public dashboard until the operator explicitly opts it in.

Feasibility: The implementation is straightforward with low risk:

1. Schema — add publish: bool = False to ProjectConfig in config/schema.py:282
2. Snapshot filtering — after VACUUM INTO at cli.py:1210, open the snapshot copy and DELETE FROM runs WHERE project NOT IN (...) followed by DELETE FROM items_touched WHERE run_id NOT IN (SELECT run_id FROM runs). This avoids touching the live DB. The snapshot is already a disposable temp copy.
3. Row count — update row_count to count only published-project runs (currently counts all rows at line 1229)
4. Tests — test_publish_db.py needs ProjectConfig instances added to _make_config with publish=True/False to verify the filter works

Risks & concerns:

• VACUUM INTO cost: Even with filtering after the fact, the VACUUM duplicates the entire DB first. For very large DBs this wastes IO. Consider building the snapshot via CREATE TABLE AS SELECT instead, or deferring (a 10 MB DB is negligible; a 1 GB DB isn't). Fine for current scale.
• dependabot_alerts table? The runs+items_touched tables cover all current dashboard data. If a future migration adds a project-specific table, it must also be filtered — no mechanical enforcement today.
• Config-drift safety: Existing configs with projects that were implicitly public will silently stop publishing them until publish = true is added. The maintainer has already noted this is intentional ("fails safe").

Open questions:

• Should the row count in the manifest reflect only published runs (matching what the dashboard shows), or all runs? Publishing total row count but filtering individual rows would be misleading. I think matching is correct per the "row-level exclusion" design.
• labro publish-db currently rewrites the projects table via upsert_projects to reflect current config, then vacuum-copies. With filtering, the projects table in the snapshot should also exclude non-published projects — handled naturally since upsert_projects only inserts projects we pass it (which would be filtered to published ones).

Recommended approach: Implement as specified. The change is self-contained (schema + one function), testable via existing patterns, and carries no deployment risk since publish defaults to False. The one design choice worth confirming: should publish-db still rewrite the projects table from config before building the snapshot? If so, it should pass only published projects to upsert_projects — the non-published rows in runs/items_touched will still be in the live DB, but the snapshot will be post-filtered anyway. Simpler just to filter the snapshot after VACUUM or (even simpler) pass only published projects to upsert_projects, then VACUUM INTO, then delete remaining orphan runs from the snapshot.