CB-192: fix false credential-gap WARN under allow-list+zsh, split its log guard #194
Reference in New Issue
Block a user
Delete Branch "worker/cb-192-gap-log-11b631-2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes gitea #192 (salvaged from closed PRs #174 and #191).
Defect 1 — the WARN wording was false on the allow-list+zsh path
HerdrPeerLauncher.logCredentialGap(creds)always emitted the WARN wording ("every member pane inherits them UNBLOCKED"), even undermemberCredentials.policy: allow-liston a zsh login shell, where the generated ZDOTDIR scrub genuinely blanks the name. The line reported the control working as though it were a hole.Fix:
logCredentialGapnow takes aneffectiveAllowedset.nullkeeps the WARN (deny-by-default, and the allow-list non-zsh fallback, where nothing is ever scrubbed). The derived allow-list set — passed only from the zsh branch ofapplyEnvironmentAllowListPolicy, reachable only after that method's own zsh gate (the same gatelogAllowListCoveragealready sits behind) — selects a new INFO wording that says the scrub will blank the name instead of claiming it is inherited unblocked. The wording is keyed on whether that set was actually computed, never oncreds.isAllowList()alone (the trap PR #174 fell into).Defect 2 — one AtomicBoolean could suppress the report that matters
memberCredentialsis a live, re-read-per-spawn supplier, so the policy can change between two spawns on one launcher. A singlecredentialGapLoggedflag meant a harmless allow-list INFO on spawn 1 could permanently suppress a genuine deny-by-default WARN on a later spawn after a config reload.Fix: split into
unprotectedGapLogged(WARN branch) andallowListGapLogged(INFO branch) — one guard per report kind.Tests
Added to
ClaudeCodeLauncherTest(which exercises the realbaseEnv()path —HerdrPeerLauncherAllowListWiringTest's fixture overridesbuildLaunchand bypassesapplyMemberCredentialPolicyentirely, so it cannot prove defect 2):denyByDefaultKeepsTheExactCredentialGapWarn— pins the deny-by-default WARN text byte-for-byte.allowListPolicyOnZshReportsTheGapWithoutClaimingItIsUnblocked— allow-list+zsh gets the INFO wording, never "UNBLOCKED".allowListPolicyOnNonZshKeepsTheWarnWording— allow-list+non-zsh (SHELL=/bin/bash) keeps the WARN, never claims a scrub.secondSpawnStillWarnsAfterPolicyChangesFromAllowListToDenyByDefault— two spawns on one launcher (allow-list+zsh, then a live-supplier reload to deny-by-default) — the second WARN still fires.Each fix was proved by reverting it locally and watching its new test fail, then restoring it (see PR description discussion / ticket #192 for the failure text quoted back to the lead).
Build
cd fleetd && mvn clean install—Tests run: 1016, Failures: 0, Errors: 0, Skipped: 0,BUILD SUCCESS.Did not touch
fleetd.yamland did not redeploy the daemon, per the ticket's instructions.logCredentialGap(creds) always emitted the WARN wording ("every member pane inherits them UNBLOCKED"), even under memberCredentials.policy: allow-list on a zsh login shell, where the generated ZDOTDIR scrub genuinely blanks the name. The line reported the control working as though it were a hole. Pass an effectiveAllowed set instead: null keeps the WARN (deny-by-default, and the allow-list non-zsh fallback, where nothing is ever scrubbed); the derived allow-list set (only reachable after applyEnvironmentAllowListPolicy's own zsh gate) selects a new INFO wording that says the scrub will blank the name instead of claiming it is inherited unblocked. Also split the single credentialGapLogged AtomicBoolean into two guards (unprotectedGapLogged / allowListGapLogged) — one per report kind. Since memberCredentials is a live, re-read-per-spawn supplier, a shared flag let a harmless allow-list INFO on one spawn permanently suppress a later spawn's real deny-by-default WARN after a policy reload. Fixes gitea #192.