CB-633 follow-up: union memberCredentials.allow into the derived env allow-list #179

2026-08-28T00:56:48+02:00

agent commented

2026-08-28 00:56:48 +02:00

Fixes the CB-633 follow-up defect: MemberEnvAllowList.derive only looked at profile fields (INFRASTRUCTURE_PASSTHROUGH, gitTokenEnv/gitHostEnv/tokenEnv/env), so memberCredentials.allow: was silently ignored under policy: allow-list. Turning the policy on would have blanked credentials an operator explicitly allow-listed.

Changes

MemberEnvAllowList.derive(profiles, configuredAllow): new overload that unions memberCredentials.allow: names into the derived set. SSH_AUTH_SOCK is explicitly excluded from that union with a comment explaining why (it is a live ssh-agent handle, not a value, so it stays governed only by sshAuthSock: allow).
HerdrPeerLauncher.applyEnvironmentAllowListPolicy now threads creds.allowSet() into the derivation via a new derivedAllowedNames(creds, launch) helper, instead of calling the profiles-only derive overload.
Added logAllowListCoverage: one INFO line per allow-list spawn, member credentials: allowed N of M (N/M computed from the existing hostEnvNames proxy for the daemon's own environment). Never logs a blocked variable NAME or a VALUE.

Tests

MemberEnvAllowListTest: a name that appears only in memberCredentials.allow: survives derivation; SSH_AUTH_SOCK is excluded from that union even when listed in allow:.
HerdrPeerLauncherAllowListWiringTest (the real launcher spawn path, via HerdrPeerLauncher#spawn — not a direct call to MemberEnvAllowList.derive):
- an operator-configured allow:-only name reaches the generated scrub script;
- SSH_AUTH_SOCK stays out of the generated scrub even when listed in allow: (sshAuthSock unset);
- the member credentials: allowed N of M log line is asserted with real, non-constant N/M against a real spawn.

mvn clean install: BUILD SUCCESS, Tests run: 975, Failures: 0, Errors: 0, Skipped: 0.

Ref: CB-633 follow-up ticket.

Fixes the CB-633 follow-up defect: `MemberEnvAllowList.derive` only looked at profile fields (INFRASTRUCTURE_PASSTHROUGH, gitTokenEnv/gitHostEnv/tokenEnv/env), so `memberCredentials.allow:` was silently ignored under `policy: allow-list`. Turning the policy on would have blanked credentials an operator explicitly allow-listed. **Changes** - `MemberEnvAllowList.derive(profiles, configuredAllow)`: new overload that unions `memberCredentials.allow:` names into the derived set. `SSH_AUTH_SOCK` is explicitly excluded from that union with a comment explaining why (it is a live ssh-agent handle, not a value, so it stays governed only by `sshAuthSock: allow`). - `HerdrPeerLauncher.applyEnvironmentAllowListPolicy` now threads `creds.allowSet()` into the derivation via a new `derivedAllowedNames(creds, launch)` helper, instead of calling the profiles-only `derive` overload. - Added `logAllowListCoverage`: one INFO line per allow-list spawn, `member credentials: allowed N of M` (N/M computed from the existing `hostEnvNames` proxy for the daemon's own environment). Never logs a blocked variable NAME or a VALUE. **Tests** - `MemberEnvAllowListTest`: a name that appears only in `memberCredentials.allow:` survives derivation; `SSH_AUTH_SOCK` is excluded from that union even when listed in `allow:`. - `HerdrPeerLauncherAllowListWiringTest` (the real launcher spawn path, via `HerdrPeerLauncher#spawn` — not a direct call to `MemberEnvAllowList.derive`): - an operator-configured `allow:`-only name reaches the generated scrub script; - `SSH_AUTH_SOCK` stays out of the generated scrub even when listed in `allow:` (sshAuthSock unset); - the `member credentials: allowed N of M` log line is asserted with real, non-constant N/M against a real spawn. `mvn clean install`: BUILD SUCCESS, `Tests run: 975, Failures: 0, Errors: 0, Skipped: 0`. Ref: CB-633 follow-up ticket.

agent added 1 commit 2026-08-28 00:56:48 +02:00

CB-633 follow-up: union memberCredentials.allow into the derived env allow-list

CI / build (pull_request) Successful in 1m7s

Details

CI / contract (pull_request) Successful in 1m16s

Details

82e7be564c

MemberEnvAllowList.derive only ever looked at profile fields, so
memberCredentials.allow: was silently ignored under
policy: allow-list — turning the policy on would have blanked
credentials working members already depended on.

- derive(profiles, configuredAllow) unions memberCredentials.allow
  into the derived set, with SSH_AUTH_SOCK explicitly excluded from
  that union (it stays governed only by sshAuthSock: allow).
- HerdrPeerLauncher threads MemberCredentials.allowSet() into the
  derivation instead of calling the profiles-only overload.
- Added a per-spawn INFO log 'member credentials: allowed N of M'
  (N/M from the daemon's own env, the existing hostEnvNames proxy),
  never logging a blocked name or a value.

ltms added 1 commit 2026-08-28 01:00:45 +02:00

CB-633 follow-up: only log allowed N of M when the scrub actually runs

CI / contract (pull_request) Successful in 53s

Details

CI / build (pull_request) Successful in 1m44s

Details

65ccf2e4ad

The coverage line was logged before the zsh gate, so a non-zsh
spawn (where nothing is scrubbed — overlayBlockedCredentials is the
fallback instead) printed 'allowed N of M' as if the derived
allow-list scrub had run. Move the log after the gate so it only
fires on the path that actually generates the ZDOTDIR scrub; the
non-zsh fallback keeps logCredentialGap's WARN as its only signal.

Added a test proving no 'allowed N of M' line is emitted on the
non-zsh fallback, through the real HerdrPeerLauncher#spawn path.

ltms merged commit 42731833d0 into main

2026-08-28 01:10:18 +02:00

ltms deleted branch worker/cb633-allowlist-union-90fa4d-1

2026-08-28 01:10:18 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fleet/fleetd#179