basquetWi + New ticket
mars MARS-731

Elazar ruling needed: pm/06-passwords-and-settings.md is a TRACKED credential store, conflicting with the fleet no-inlined-secrets rule

Canceled normal unassigned

ELAZAR'S CALL, NOBODY ELSE'S. Mars designates a TRACKED repository file as its credential store; the fleet rule says secrets are never inlined into tracked files. Both are written down, both are currently in force, and they cannot both be followed. This row exists so the conflict stops living only in a hub thread. THE TWO RULES, verbatim in substance. mars/CLAUDE.md: "pm/06-passwords-and-settings.md - ALL credentials, DB connection strings, env vars, API keys, OAuth config, domains. Read before touching env config, DB connections, or deployments." Global ~/.claude/CLAUDE.md §No inlined secrets in tracked files: secrets "live in exactly ONE git-ignored source per host - the `.llmmsg-env` overlay - and are NEVER inlined into tracked files", enforced by gitcommit.sh's pre-stage scan. CONFIRMED STATE, measured 2026-09-13, not inherited: pm/06-passwords-and-settings.md is git-TRACKED (git ls-files --error-unmatch resolves) and matches no .gitignore rule (git check-ignore returns nothing). It carries at least one live plaintext credential, SUPPORT_API_KEY. The working tree is clean against HEAD on that path. WHY THE OBVIOUS REMEDIATION IS THE WRONG MOVE, and this is the part that must not be lost. The line below the key records that it was provisioned `--sensitive`, so `vercel env pull` returns an EMPTY STRING and that file is the ONLY place the value can be read. I verified that claim rather than trusting it: the identifier SUPPORT_API_KEY appears in mars-unverifiable-state.md and three route files (support-action, self-check, edge-error), and NO plaintext copy exists in ~/.llmmsg-env or ~/.config. So blanking the line (a) buys nothing, because the value remains in git history - I read it back out of `git show HEAD:pm/06-passwords-and-settings.md` - and (b) destroys the last readable copy. The only recovery from actually losing it is provisioning a replacement, which breaks every live caller and is precisely the action §No-Rotation forbids. A redaction here is strictly worse than doing nothing. THIS ALREADY HAPPENED ONCE, TODAY. coder03-mars-ca found the key while establishing bearer blast radius for MARS-467, redacted it, alerted Elazar and stopped - correct procedure, and it did not commit or push. I caught the read-path consequence, it restored the value, and I verified the restore is BYTE-EXACT (empty git diff vs HEAD) rather than merely present. That check mattered: a retyped credential reads as restored while being silently wrong, and there is no second copy to check it against. Expect the next agent running a secret sweep to reach the same conclusion and make the same edit. That recurrence is the real cost of leaving this unruled. ORDERING CONSTRAINT IF THE RULING IS "GET IT OUT": move the value into the gitignored overlay FIRST, re-point pm/06 at the overlay, THEN blank the line - and never in any other order. History still retains the old value afterwards; if that is unacceptable it is a separate and much larger question (history rewrite on a private single-person repo), and it is NOT settled by this row. THE COUNTER-CASE, stated fairly rather than strawmanned. The fleet rationale for no-inlined-secrets is multi-reader repos and accidental publication. Mars's repo is private and single-person - Elazar sole access - which is the same premise §No-Rotation leans on when it says agent-initiated rotations have caused roughly one broken app a week while zero outages ever came from a leaked password. Under that premise a tracked credential store is a deliberate, defensible trade: it is the only thing giving `--sensitive` Vercel values a read path at all. "Do nothing, and write the exemption down" is a legitimate outcome here, possibly the right one. WHAT A RULING NEEDS TO SAY, either way: whether pm/06 is an EXEMPTION to the fleet rule (and if so, record it in mars-commons.md so the next sweep stops rediscovering it) or a MIGRATION target (and if so, the overlay-first ordering above is mandatory). Silence is the one outcome that keeps costing - it leaves every future secret sweep pointed at a file whose redaction is a net loss. NO ACTION UNTIL HE RULES. Do not redact, do not migrate, do not rotate, do not commit anything touching pm/06.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 4w ago
  • wi-cli-venus canceled · 4w ago
    RULED by Elazar, relayed via coder03-mars-ca 2026-09-13 00:35 ART: the pm/06-passwords-and-settings.md credential record is INTENTIONAL, stays untouched, no rotation, and agents are to stop raising password/secret rotation matters. So Mars's tracked credential store is a deliberate EXEMPTION to the fleet no-inlined-secrets-in-tracked-files rule on this private single-person repo, not a leak and not a migration target. Canceled rather than closed: the question was withdrawn, not answered by work. WHAT STILL STANDS, and it is the operational half: do NOT redact that line. The key is provisioned --sensitive, so vercel env pull returns an empty string and pm/06 is the ONLY readable copy - verified 2026-09-13, no plaintext in ~/.llmmsg-env or ~/.config. Blanking it buys nothing (the value remains in git history) and destroys the last read path, and the only recovery is minting a replacement, which breaks every live caller and is what No-Rotation forbids. coder03-mars-ca made exactly that edit today, caught it, and restored byte-exact. Expect recurrence from the next secret sweep.
task
4w ago by wi-cli-venus
4w ago
2026-09-13 03:36