[p4gs]

DO NOT MERGE YET

The sibling site repo must register these six control ids — with the classes in the table below — before this lands, or every directory scan fails closed. That ordering is being handled separately.

---

sscsb stopped where the artifact left. Phases 1–5 harden the repository, the dependencies it consumes, the CI that builds it and the files a GitHub Release carries; none of them covers the moment that artifact goes to crates.io, npm, PyPI, Homebrew, Chocolatey or WinGet, and none covers the credential that lets it. That is the Shai-Hulud / chalk-debug shape exactly: phish a maintainer, take a long-lived publish token, ship malware under a trusted name. No commit is involved, so every control we already had was looking the other way.

48 controls → 54. (Branched one commit before socket-firewall-ci landed; main has since been merged in, so the counts here are against current main.)

Control	Class	Default	What it checks
publish-targets	A	on	Inventory of what this repo publishes, and the manifest that proved it. Never grades.
trusted-publishing	A′	on	OIDC publish workflow + a gated release environment; no stored registry token.
maintainer-mfa	C	on	GitHub 2FA, npm tfa.mode, and a dated phishing-resistance claim.
publish-tokens	A′	on	Committed credential files, avoidable long-lived secrets, declared-token expiry.
publish-provenance	B	on	Probes the live registry for provenance on what was actually published.
dist-manifests	A	on	Homebrew sha256, Chocolatey checksum + checksumType, WinGet InstallerSha256.

All six ship on, and phase 6 adds no off-by-default control, because the gate is detection rather than configuration. Every verifier goes quiet when its target is not in the tree, and degrades — naming the degraded_reason — rather than failing when a tool or credential is simply absent.

Design decisions worth reviewing

Publish templates live in their own DIST_ARTIFACTS table, not workflows::ARTIFACTS. That table installs on control-enabled alone and trusted-publishing is on by default, so registering them there would have dropped publish-npm.yml into every repository sscsb ever touched. A publish workflow you do not publish with is not a harmless extra file; it is a workflow_dispatch button wired to somebody else's namespace. A test asserts the separation rather than only commenting it.

The environments read follows verify_branch_protection literally. GitHub answers 404 for both "no such environment" and "your token cannot see environments" — opposite verdicts — so the ambiguous case degrades and says which two things it might be. Telling a maintainer to create an environment that already exists is how a tool teaches people to stop reading it.

npm tfa.mode = auth-only FAILS; a missing GitHub two_factor_authentication field DEGRADES. auth-only gates login but not the publish itself, which is the precise gap a stolen session walks through. GitHub omits the field for a token without read:user, and reading that as false would accuse a maintainer holding a passkey of having no second factor. That read is also gated on a resolvable GitHub remote: without one, the account gh is logged in as is whoever owns the laptop, not whoever owns the package.

Attestations document, never upgrade. [[token]] expires and [signing] expires go through signers.rs's own evaluate_expiry; an expired claim fails. [[account]] attested deliberately does not — it counts backward from the day a human last checked, where a bigger gap is worse, and feeding it to an expiry evaluator would type-check while grading a claim dated tomorrow as comfortably fresh. Both directions are pinned by a test.

Six phase bounds were hard-coded to 5 — one would have mis-scored every repo

controls.rs (×2), cli.rs, compliance.rs and tests/skill_docs.rs each iterated 1..=5, so phase-6 controls would not have appeared in status, report, or the registry's sparseness guard.

The one that mattered is machine.rs's score_of, which built score.phases[] from 1u8..=5. A phase-6 row would have fallen out of both the numerator and the denominator while still counting toward scoped — so adding six passing controls would have lowered every repository's evidence-coverage percentage in the directory record. Now PHASE_COUNT, derived from the registry, because the number is a wire contract with the site.

config.rs had the same latent bug in prose: _ => "Phase 5 — Observability & governance" is correct exactly until a sixth phase exists, then prints a wrong heading in the one file every user edits. Phases 5 and 6 get explicit arms, the fallback is a visible bug marker, and a test asserts no control renders it.

Two defects found by dogfooding, not by reading code

1. publish = false was ignored. fuzz/Cargo.toml carries it, and detection called it a crates.io target — a crate that cannot be published even deliberately. publish = false and publish = [] are now honoured; publish = ["registry"] still counts.
2. This repo's own root manifest carries publish = false too, so sscsb is not on crates.io at all — while the README's first install line is brew install p4gs/p4gs/sscsb, from a tap in another repository that nothing in this tree can prove. Without [targets] homebrew = "on", sscsb would have reported that its own project publishes nowhere. That declaration is committed here with its reasoning, as the worked example of why the override exists — and the checksum controls now say the manifest lives elsewhere instead of degrading over a file that was never supposed to be here.

sscsb dist, and no sscsb publish

dist status and dist check [--strict] land. A publish wrapper was considered and rejected; docs/phase-6.md records all three reasons so nobody re-proposes it — git hooks fire on git events and nothing intercepts npm publish; the doctrine here is to move publishing into CI behind an OIDC identity; and reimplementing six registries' publish clients buys no security property.

Verification

Local suite (--no-fail-fast, hermetic invocation per CLAUDE.md), against a main baseline taken the same way:

	passed	failed
baseline (main @ 8cad3f0)	987	33
this branch (pre-merge)	1046	33
this branch (after merging main)	see CI	—

The 33 are identical in both runs and all environmental to this agent sandbox: DNS is blocked (so deps baseline cannot reach crates.io, which fails the shared rust_repo() fixture and takes all 15 tool_orchestration tests with it), opengrep is on PATH but opengrep --version fails, and binding a local socket is denied (dtrack). cargo fmt --check and cargo clippy --all-targets --locked -- -D warnings are both clean.

Dogfood verdict on this repo — 0 failed, 1 degraded, exit 0:

[INFO    ] publish-targets      Homebrew ← distribution.toml [targets] override
[INFO    ] trusted-publishing   Homebrew has no Trusted Publishing path (publishes by PR)
[DEGRADED] maintainer-mfa       GitHub `p4gs`: two_factor_authentication absent — token lacks
                                read:user; run `gh auth refresh -s read:user`. Unverified,
                                NOT a confirmed absence of 2FA
[PASS    ] publish-tokens       no committed credentials, no long-lived registry secrets
[INFO    ] publish-provenance   Homebrew formula lives in the tap repo
[INFO    ] dist-manifests       Homebrew manifest lives in the tap repo

That degrade is the designed path, exercised live against the real GitHub API rather than a fixture.

Known-stale, deliberately untouched

docs/example-walkthrough.md still says 43 controls — it was already stale by four on main, nothing tests it, and re-capturing it honestly needs a terminal with network and every scanner present, which this environment does not have. Fabricating updated numbers would be worse than a disclosed pre-existing drift. Worth its own pass.

[p4gs]

CodeQL: 12 rust/cleartext-logging alerts — disposition, and a decision for you

CodeQL reports 12 high-severity rust/cleartext-logging alerts against this PR. It is not a required check here (lint, test, coverage are), so it does not block — but this repo's rule is zero-tolerance on suppression, so here is the evidence rather than a shrug. I have added no suppression of any kind — no // lgtm, no #[allow], no query-filter exclusion.

What the alerts are

All 12 are the same rule, and all the sinks are test-assertion panic messages:

Location	Sink
src/distribution.rs ×11	assert!(…, "{:?}", r.messages) inside #[cfg(test)]
tests/library.rs:1317	pre-existing — this is main's tests/library.rs:1316, re-reported because line numbers shifted

This class is pre-existing on main

main currently has 5 open rust/cleartext-logging alerts of the same shape:

src/hooks.rs:532
tests/library.rs:1316
tests/library.rs:148
tests/library.rs:122
tests/library.rs:156

So this PR does not introduce the class; it adds instances of an existing, unresolved one.

Evidence-based determination

The taint source CodeQL reports is the function itself — verify_maintainer_mfa(...), verify_trusted_publishing(...), references_token_secret(...). That is the rule's name-matching heuristic firing on mfa / token / secret in identifiers, not a value-flow finding.

I audited every path that builds a message in src/distribution.rs. No credential value can reach one, by construction:

• verify_publish_tokens reads .npmrc / .pypirc content and tests line.contains(marker). The message carries the path and the marker key (_authToken) — never the line, never the value.
• references_token_secret returns secret names (NPM_TOKEN), matched against secrets.<NAME>; it never reads a value, and values are not available to it.
• npm_tfa / github_two_factor use profile["name"] and user["login"] — usernames, not credentials — plus tfa.mode.
• The only unbounded external text in any message is out.stderr.lines().next(), which is the house-standard pattern already used by webhooks.rs and audit.rs.

A grep for file/command content flowing into messages.push/format! returns only paths and key names.

What I changed anyway

One genuine hygiene fix, not an appeasement: the .npmrc test fixture's value is now EXAMPLE instead of a string shaped like a real npm granular token. The detector keys on the marker and never on the value, so the realistic literal bought the test nothing while putting a token-shaped string into this repository's history — which is the thing the control exists to prevent.

What I deliberately did not do

The only mechanical way to clear the remaining alerts is to stop printing r.messages in assertion failures, or to rename the verifiers away from mfa/token/secret. Both make the code worse — the first removes the diagnostics that make a failing test debuggable, the second makes the functions lie about what they do — and neither removes a real exposure. Per the repo rule, a suppression needs your documented determination, not mine, so:

Decision for you. Either (a) accept the class as it stands on main, (b) have me strip the message payloads from these assertions repo-wide (I'd argue against it), or (c) dismiss the alerts in the Security tab with the rationale above. I've done none of them.

[p4gs]

CodeQL follow-up: I was wrong first time, there WAS a real bug, and it is fixed. The remaining alerts are name-driven.

Two separate things were tangled together here. Splitting them.

---

1. There was a real exposure, and my first analysis missed it

My earlier comment checked the sinks CodeQL named — assertion strings in the test module — concluded no credential reached them, and stopped. That was the wrong place to stop.

A VerifyResult's messages are not only printed. machine.rs serializes them into --format json and into the local-scan record that is signed, committed, and published to the public directory. A message is an artifact with a signature on it.

maintainer-mfa and trusted-publishing are the only controls in sscsb that ask a credential-holding command about an account — gh api user and npm profile get --json both answer as the logged-in maintainer. Six production sites were copying those answers into messages verbatim:

• the first stderr line of a failed gh api, gh api user, and npm profile get. npm puts the registry URL in its errors, and a misconfigured .npmrc makes that URL carry inline basic-auth — that is the dangerous one, not a hypothetical;
• login from the GitHub user payload, and name from the npm profile payload (whose siblings include email);
• the raw tfa.mode string;
• an unrecognised protection_rules[].type from the environments payload.

Fixed in 035c2d5. The rule for the module is now narrow and absolute: no byte of a tool's stdout or stderr is ever copied into a message. Only the specific field is read (two_factor_authentication, tfa.mode); free-form strings go through safe_label (bounded charset and length, refused whole rather than truncated — a truncated secret is still a secret prefix); failures report an HTTP status via tool_failure, which is the whole diagnostic value of the line it replaces and the one part that cannot carry a credential. Parse failures withhold the payload too. Spawn errors are exempt and documented as such: they carry our own argv and an OS message, never anything a registry said.

no_tool_output_is_ever_echoed_into_a_published_message hands both verifiers four hostile answers with a planted marker and asserts it reaches no message. It caught a leak on its first run, after the sanitizer was already in: tfa.mode was still being echoed, because safe_label correctly passed the planted value — a secret can be perfectly well-formed as an identifier. tfa.mode is a closed enum, not a name, so an undocumented value is now reported as undocumented and withheld. That bug would have shipped without this test.

Thank you for pushing back on the first read.

2. The 17 remaining alerts are not about the data, and redaction did not move them

The count went 12 → 17 across the redaction commit, which by itself shows the alerts do not track the payload. The reported sources say why:

11  verify_maintainer_mfa(...)
 3  ...::verify_secrets_control(...)
 2  verify_trusted_publishing(...)
 2  ...::verify_maintainer_mfa(...)
 1  references_token_secret(...)

verify_secrets_control is the proof. It is pre-existing, untouched by this PR, and it already alerts on main:

src/hooks.rs:532      — writes run_secret_scan_staged(...) to a log file
tests/library.rs:122  — writes ...::verify_secrets_control(...) to a log file
tests/library.rs:148  — writes ...::verify_secrets_control(...) to a log file
tests/library.rs:156  — writes ...::verify_secrets_control(...) to a log file
tests/library.rs:1316 — writes ...::verify_secrets_control(...) to a log file

rust/cleartext-logging classifies the call expression by NAME — mfa, secret, token — and treats its return value as sensitive regardless of content. run_secret_scan_staged returns a count of findings. verify_secrets_control returns a verdict about secret scanning. Neither has ever carried a credential. No amount of sanitizing what a function returns changes the name of the function that returned it, which is why the fix in §1 — a genuine fix — did not move the count.

This is the "scanner fundamentally cannot model it" determination, with evidence. The three ways to clear these:

1. Rename the verifiers away from mfa/secret/token. They would then lie about what they do, and it would mean renaming pre-existing public functions. Renaming code purely to dodge a name heuristic, with behaviour unchanged, is suppression wearing a different hat — so I did not do it, including for references_token_secret, which is mine and which I could have quietly renamed.
2. Stop printing verifier results in assertion messages. That removes the diagnostics that make a failing test debuggable — this repo's own house style leans hard on them.
3. Suppress. Forbidden, and I have added none: no #[allow], no inline CodeQL comment, no query-filter exclusion.

Over to you, as agreed — I am not making this call unilaterally. Options: (a) accept the class as it already stands on main; (b) dismiss these alerts in the Security tab as used in tests / false positive with the rationale above; (c) tell me to strip message payloads from assertions repo-wide (I would argue against it).

Required checks

lint, test, coverage — the three required by branch protection — plus Fuzzing are green. CodeQL is not a required check here.

Two CI-only failures were found and fixed along the way, both the "green locally, red on the runner" class this repo's CLAUDE.md documents:

• c76c628 — fake_tool shims had no #!/bin/sh. macOS execs a shebang-less text file by falling back to /bin/sh; Linux returns ENOEXEC (Exec format error (os error 8)). Fixed once in write_shim so the next caller's omission is harmless, with a regression test that runs a shim rather than inspecting its bytes.
• b806e22 — only_git_on_path() hid gh on my Mac (/usr/bin/git vs /opt/homebrew/bin/gh) and not on a runner, where both are in /usr/bin, so two tests asserted a degrade they had never set up. Switched to hide_from_path(&["gh"]), and each now asserts its own precondition before running the verifier.

src/distribution.rs coverage also went 83.59% → 94.55% lines (total 96.88% lines / 96.42% functions).