VENUS-350(a): verify gpg passphrase blast radius, then retention, then a second secrets location before filtering vault.secrets from the pg_dump
Carved out of VENUS-350 under the 2026-10-06 ruling (blackboard bb-pmmaster-evolutiva-cc-muw8fnwy-qaowpv, 4/4). This is the engineering half; the destructive purge and the spend call are separate rows for Elazar. ORDERED STEPS, do not reorder - step 1 decides the rest. STEP 1 (blocking, cheap, a read): state WHERE the gpg passphrase for the venus backup dumps lives, and whether that location is reachable from the SAME blast radius as the gdrive mount - same Google account, same host, a file the backup script or a compromised account can read. Both KEEP positions on the blackboard rest entirely on this one assumed property and nobody has ever examined it. Reachable from the same radius -> gpg is decorative, filter immediately and accept the recoverability hit, there is no mitigation left to weigh. Independently held -> continue to step 2. Do NOT paste the passphrase or its contents anywhere; the deliverable is its LOCATION and reachability, not its value. STEP 2: answer whether a restore drill has EVER been exercised against these dumps. If not, say so plainly - 'a complete backup preserves recoverability' is then an untested claim on the same footing as 'gpg is sufficient', and the whole KEEP case rests on it. STEP 3: forward retention policy on the vault-bearing copies. This is the lever the measurement actually supports: N copies of one secret is still one secret, so cadence multiplies opportunities, not exposure - RETENTION multiplies exposure, and under the fleet no-rotation rule an 18-month-old dump holds a CURRENTLY VALID credential forever with no expiry anywhere. Cutting forward retention depth reduces exposure without touching recoverability. Forward policy only; purging what already exists is destructive and lives on the sibling row. STEP 4, only after 1-3: build the separate secrets export - infrequent, written on secret CHANGE not every two hours, access-controlled, held where the fleet keeps its other root-of-trust material and NOT on the gdrive mount. vault.secrets is a wrapper around values that came from somewhere else, so the real requirement is that the secrets be independently recoverable WITHOUT the dump. VERIFY a restore reads that export. THEN and only then filter vault.secrets out of the pg_dump. Filtering before the second copy is verified converts a bounded confidentiality risk into an unbounded availability one and will not be accepted. HARD CONSTRAINT: no credential or password rotation at any point, for any reason - fleet standing rule, and it is what makes step 1 load-bearing, since a leaked passphrase here has no fix.
Activity
-
parent=#2423
-
STEP 1 RESULT (location + reachability; no value disclosed). The passphrase is VENUS_BACKUP_PASSPHRASE in venus:~/.venus-db-backup.env (rob 0600). Not in /data-venus (grep -rlIF of the value, backups/ excluded). REACHABLE FROM THE GDRIVE RADIUS anyway: the value is present verbatim in (a) ~/.claude/ltm.md lines 420/426 and (b) the hub v2.sqlite snapshot. Both are members of the venus-state-backup daily bundle (/home/rob/scripts/venus-state-backup.sh, owner nw-venus-cc), shipped UNENCRYPTED to gdrive:remotedocs/backup/agent-state/venus (14 kept) and the whey USB outbox (30 kept). Verified by streaming venus-state-20261006-0330.tar.gz. The same bundle also carries venus/.env.local (live DSN + service-role), so a gdrive-account compromise yields live prod DB access regardless of dump gpg or vault filtering. This bundle design is Elazar's 2026-06-14 GO (no encryption; gdrive sole-access = trusted). STEP 2: a restore drill EXISTS and has fired unattended: venus-db-backup-verify.timer PASS 2026-10-05 12:37Z and 2026-10-06 00:36Z (86 tables). Caveat: it decrypts with the on-host passphrase, so it proves restore WITH venus, not restore from the off-host copies alone. Escalated kind=blocked to pmmaster: the row's premise that filtering reduces gdrive exposure is false.
-
Closed by pmmaster-evolutiva-cc 2026-10-06 on option B, per coder-venus-cc's step-1 finding (coder-venus-cc-muwa5ymoe1sx) and its own recommendation. The row's step 1 FALSIFIED the row's premise rather than completing it, which is the outcome worth recording. VENUS-442 proposed filtering vault.secrets out of the pg_dump to reduce what a leaked backup exposes. Step 1 measured that the same daily backup bundle already ships the dump passphrase and venus/.env.local - live DSN and service-role - unencrypted to the same destinations. So the proposed filtering buys approximately zero confidentiality against the path that actually exists, while costing real recoverability: a dump missing vault.secrets is a dump that cannot fully restore. Option A (filter) DECLINED on that basis. The generalisable point: a hardening step is worth what it closes relative to the paths left open, and sizing it requires enumerating the other paths FIRST. A control that reduces capability while leaving the cheaper route untouched is not a partial win, it is a loss - this one would have degraded restores in exchange for nothing. Step 2 also closed clean: the restore drill exists and has PASSed unattended twice, so the recoverability concern was not hypothetical. The real exposure is not dropped - it is raised to the party who owns the decision, as VENUS-446 (Elazar, p1, nw-venus-cc), because the unencrypted state bundle is his explicit 2026-06-14 GO and reversing it is his call. No credential is rotated: the fleet no-rotation rule is absolute and nothing here is grounds for an exception. No value was disclosed on either row.