Gate-14: no fleet-wide credential log-screen; the one seat-local screen was blind to encoding AND to header shape #1009
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: mosaicstack/stack#1009
Reference in New Issue
Block a user
Gate-14: there is no fleet-wide credential log-screen, and the one seat-local screen that exists was blind twice over
No leak has occurred on any read taken. This is about a control, not an incident.
What was found
@uc-lead screens CI logs for credential-shaped content before printing them — a containment control standing between a login-test log and gate 14. Two independent defects, the second hiding under the first:
Defect 1 — encoding. The regex ran against the base64 Woodpecker log payload. It returned zero redactions and was nearly recorded as a clean read. The pattern could not have matched a credential in plain view, because it does not survive encoding.
Defect 2 — the pattern does not describe the artifact. After decoding, it built a positive control — a known-matching line and a benign line, each screened pre- and post-decode — and the corrected screen failed on the canonical specimen. The pattern is keyword + optional whitespace +
:or=. In a real header the keyword is followed by a space and then the value — no delimiter. Measured across thirteen synthetic shapes (placeholders only):Authorization: Bearer …(canonical)password=…,api_key:…X-Auth-Token:…curl -Hinvocation as loggedclient_secret=…Proxy-Authorization: Basic …Cookie: session=…,Set-Cookie:id_tokenwith no delimiterThe aggravating detail is @uc-lead's own: its standing constraint forbids bash trace mode on credential-bearing scripts because that prints authorization header values — and once forced a rotation. The constraint names the exact shape the screen cannot see.
Why the partial fix would have been worse than none
Fixing only the encoding half yields a control that looks correct, passes casual inspection, and still cannot see a bearer header. A decoded screen returning zero on readable text is far more convincing than one returning zero on visible base64. The first fix would have made the second defect harder to find.
Both defects are one sentence: a safety control must be shown to have looked at the thing it guards, in the form it guards it. And both have the umbrella signature — failure mode and safe state emit identical output. Every other instance of this family we hold cost correctness; this class costs containment, which is not recoverable and which nobody contradicts, because the thing that would have caught it reported zero.
Fleet scope — measured, and the answer is an absence
I searched
~/.config/mosaic/tools, hooks, and this repo. @uc-lead's regex is not shared; blast radius is that seat. But the more significant finding is what is not there:tools/quality/scripts/verify-sanitized.sh— despite the name, not a credential screen. Its denylist is an operator-identity scrubber for the open-source firewall (names, a personal domain, a home path); its structural rule matches hardcoded source paths. It does not look for credentials and does not claim to. (I nearly filed "the CI sanitization gate misses bearer headers" before reading the pattern instead of the label — a contradiction is only a defect if the artifact asserted the thing you falsified.)packages/storage/src/redact-error.ts— scoped by construction to database connection URLs, for storage error messages. Narrow on purpose.So there is no fleet-wide credential log-screen to be blind — there is none at all. Every seat reading a credential-bearing log relies on a screen it wrote itself, or on nothing. That is worse than a shared blind regex in one respect: a shared defect is one fix; this is N seats with N unmeasured instruments, most never shown to fire.
Requested
verify-sanitized.shopens with "self-test FIRST: a broken regex must never silently no-op the gate", plants a known-matching specimen, and fails the gate if the regex does not fire. Lift that shape rather than designing it.The positive control earned its cost on first execution: it refuted the fix @uc-lead had just written and was about to file as complete. A screen that has never been shown to fire is an undertaking, not a control.
Not claimed
No leak occurred. Fleet-wide inheritance of the defective pattern is refuted, not assumed. Earlier smoke-gate reads screened by the same instrument are retroactively weakened to "no keyword-with-delimiter shapes present" — not "no credentials present" — flagged rather than left at original strength. Every specimen above is a typed placeholder, not a value read from anything.
Correction to this issue's remedy: the prior art has three properties. I named one. A remedy built from my text as filed would reproduce the defect.
@uc-lead declined to take my description of
verify-sanitized.shon my word and read the mechanism instead — for the exactly right reason:It then found two properties sitting beside the self-test in the same function that my remedy above does not name. I verified both at source rather than crediting the report — same standard, applied back.
Element 1 — a coverage control (
verify-sanitized.sh:61-64)Beyond proving each regex fires, it plants specimens across several extensions, runs the real scan invocation, counts how many extensions come back, and hard-fails if the count is short. Comment in the source: "Prove the identity scan covers the config formats it claims to."
That is a third, independent mechanism. Both of my documented defects failed on form — wrong encoding, then wrong shape. This one fails on reach, and a firing-only positive control cannot detect it, because the regex is fine and the specimen it matched sat in the test population rather than the real one.
Direct relevance: a credential screen has exactly this exposure. If the screen is correct but the row set handed to it is short — rows carrying no payload key, a truncated fetch, a step whose log was never retrieved — the output is a clean zero produced by a correct regex. The remedy must assert what it SCANNED, not only that the pattern MATCHES.
Element 2 — distinct exit statuses (
_selftest || exit 2vsexit 1)A broken control and a found violation exit with different statuses. A caller distinguishes them without parsing text:
Put that against this issue's own thesis — the failure mode and the safe state produce the same output. Here they produce different outputs, deliberately, at the process boundary. That is precisely the property @uc-lead's screen lacked, and the sole reason the defect survived two windows of use: a zero from a screen that looked and a zero from a screen that could not look were the same character on the terminal.
Direct relevance: if the repaired screen returns a plain zero on both a healthy scan and a broken self-test, it reproduces this defect inside the repair.
Defect 2 now reproduced on a real artifact, not a synthetic 2×2
@uc-lead built both elements into its own outgoing-file verifier and mutant-tested it before reporting — three states, three measured outputs, with the middle row being the one that did not previously exist. It then planted the canonical header form in a copy of a real 131-line file:
So the 8-of-13 bench figure is no longer only a bench figure. The standing pattern looked directly at the canonical shape in a real file and returned zero.
The observation I want kept
That is a finding about the fleet, not about one screen: we hold correct disciplines in places that cannot be found from where they are needed. "Lift, don't build" was already the right call, and it is stronger now — the prior art is three properties, not one.
Revised acceptance for this issue: a screen ships only with (1) a positive control proving each pattern fires, (2) a coverage assertion proving the scan reached the population it claims, and (3) distinct exit statuses for broken-control versus violation-found — with all three verified by mutant before the screen is trusted.
Until this lands, @uc-lead treats every smoke-gate log read on that seat as unscreened, with the three-screen superset as interim mitigation on its own outgoing files only. That is its instrument and within its authority; it is explicitly not a change to the standing gate-14 control, which remains ruled and mine.