fix(dream-cli): schema-driven secret masking + macOS Bash 4 validation

[yasinBursali]

What

Five related hardenings to dream config and its helpers:

1. Schema-driven masking in dream config show — replace the narrow keyword regex (which missed _PASSWORD, _SALT, _PASS suffixed fields) with .env.schema.json-driven detection.
2. Bash 4+ invocation — dream config validate now invokes validate-env.sh through "$BASH", and the target script adds its own Bash-4 guard. Fixes a macOS-only crash under /bin/bash 3.2.
3. Belt-and-suspenders fallback — after a schema-miss under _schema_loaded=1, fall through to the keyword match instead of returning "not secret." Covers schema gaps and malformed schemas.
4. Helper promoted to file-scope + reused by dream preset diff — _cmd_config_is_secret was nested inside cmd_config show, so dream preset diff still used the original narrow regex and leaked N8N_PASS, LANGFUSE_SALT, and admin email fields in plaintext. Helper is now file-scope; both commands use it. N8N_USER and LANGFUSE_INIT_USER_EMAIL are also marked secret: true in .env.schema.json.
5. Audit follow-up — close the jq-less Git Bash leak. python3 fallback in _cmd_config_load_secret_schema when jq is absent (Git Bash on Windows is the canonical case). Plus *user*|*email* keyword extension as belt-and-suspenders for the no-jq-no-python3 case.

Why

The narrow regex (SECRET|PASS|KEY|TOKEN)= missed suffix-form names like LANGFUSE_DB_PASSWORD, LANGFUSE_SALT, OPENCODE_SERVER_PASSWORD, etc. dream config validate crashed on every fresh macOS install because validate-env.sh uses declare -A (Bash 4+ only) but was invoked through /bin/bash 3.2. And dream preset diff was a forgotten sibling code path.

Maintainer audit (2026-04-28) flagged that the schema-driven path only fires when jq is on PATH. In Git Bash on Windows (no jq by default), the helper silently set _cmd_config_schema_loaded=0 and dream config show fell through to the keyword regex, which didn't cover *user*|*email*-suffixed names — so N8N_USER and LANGFUSE_INIT_USER_EMAIL printed in clear.

How

Five commits, each self-contained:

• d4d754ae — schema-driven masking in cmd_config show.
• cc6c40ac — Bash 4+ gate + "$BASH" invocation path.
• ce37c119 — fallback-masking hardening (*bearer* added to keyword fallback) + test-harness fix for macOS.
• 9cee345d — schema-miss falls through to keywords + helper promoted to file-scope + dream preset diff now uses the helper + N8N_USER / LANGFUSE_INIT_USER_EMAIL marked secret: true.
• 2b49c8ff — audit follow-up: python3 fallback in _cmd_config_load_secret_schema, *user*|*email* keyword extension, regression test exercising all three PATH conditions.

Audit follow-up details (commit 2b49c8ff)

_cmd_config_load_secret_schema now follows this order:

1. If jq available → use jq (existing fast path).
2. Else if python3 available → parse .env.schema.json via heredoc'd python3 and extract keys where spec.get("secret") is True. Sets _cmd_config_schema_loaded=1.
3. Else → leave _cmd_config_schema_loaded=0. _cmd_config_is_secret falls through to the keyword regex which now also includes *user*|*email* to cover the new schema secrets.

Verified: jq and python3 produce identical 36-key outputs on the live .env.schema.json (CG diff'd both, no delta).

Testing

• make lint, make test, shellcheck all green.
• New tests/test-dream-config-secret-mask.sh (7 cases, wired into make test):
  • jq+python3 both present → schema-driven jq path
  • jq absent, python3 present → python fallback
  • both absent → keyword regex fallback
  • sanity case: non-secret DREAM_VERSION=2.0.0-test shown in clear (no over-mask)
• Each PATH case asserts both positive (KEY=*** appears in stdout) AND negative (literal sensitive value does NOT leak). Sentinel values: actual-admin-username (N8N_USER), admin@example.test (LANGFUSE_INIT_USER_EMAIL).
• CG sabotage check: with both fallbacks reverted, 4 cases fail (jq-less and tools-less paths both leak). With only the keyword extension reverted, 2 cases fail (only the no-tools path leaks). Confirms each layer is independently load-bearing.
• Original PR's dream config show / dream config validate / dream preset diff testing still passes.

Review

Local CG APPROVED (no warnings). Notes from review (informational only):

• A literal-null .env.schema.json would trigger AttributeError in the python heredoc. Suppressed by 2>/dev/null and degrades to keyword regex fallback (functionally safe, just an ungraceful traceback). Could widen the except clause but project style discourages broad lists.
• The test harness's symlink-PATH approach is sensitive to the outer PATH's Bash version (only matters for manual PATH=... debugging; standard make test is unaffected).
• Over-mask risk from *user*|*email* extension is zero in current .env.schema.json — all 4 user/email-bearing keys are already secret: true. Hypothetical future operational keys (e.g., USER_HOME) would be over-masked but cat .env remains the unmasked escape hatch.

Known Considerations

A small number of operational keys (TOKEN_SPY_PORT, TOKEN_SPY_URL, LANGFUSE_PROJECT_PUBLIC_KEY) remain over-masked by the keyword fallback. This is intentional: dream config show should default to over-masking; raw values remain accessible via cat .env.

Platform Impact

• macOS: primary fix target for the validate-env crash. All five hardenings apply.
• Linux / WSL2: fixes apply identically; no platform branching.
• Windows (Git Bash without jq): the audit follow-up is the primary win — schema-driven masking now works without jq via the python3 fallback, and the keyword extension closes the residual gap.

[Lightheartdevs]

Audit follow-up: needs revision for no-jq environments.

Schema-driven secret masking is useful, but the CLI only learns the schema secret flags through jq. In Git Bash without jq, newly marked user/email fields such as N8N_USER and LANGFUSE_INIT_USER_EMAIL can still print in clear. Please either make schema parsing available without jq for this command or extend the fallback mask to cover the new schema secrets.

[yasinBursali]

Pushed audit follow-up (2b49c8ff).

Closes the jq-less Git Bash leak with two independent layers:

1. Python3 fallback in _cmd_config_load_secret_schema. When jq is absent but python3 is on PATH (the typical Git Bash on Windows configuration), parse .env.schema.json via a heredoc'd python3 -c and extract keys where spec.get("secret") is True. Sets _cmd_config_schema_loaded=1 so the schema-driven path activates. CG verified jq and python3 produce identical 36-key outputs on the live schema (diff is empty).

2. *user*|*email* keyword extension in _cmd_config_is_secret. Belt-and-suspenders for the truly-no-jq-no-python3 case. Light over-mask risk on hypothetical future operational keys; cat .env remains the unmasked escape hatch by design.

New tests/test-dream-config-secret-mask.sh (7 cases, wired into make test):

• Builds three PATH conditions via symlink farm: jq+python3, jq-excluded, both-excluded.
• Each scenario asserts N8N_USER=*** AND LANGFUSE_INIT_USER_EMAIL=*** appear in stdout AND that real sensitive values (actual-admin-username, admin@example.test) do NOT leak.
• Sanity case: non-secret DREAM_VERSION=2.0.0-test shown in clear → no over-mask regression.

Local CG APPROVED (no warnings). Sabotage-checked: with both fallbacks reverted, 4 cases fail; with only the keyword extension reverted, 2 cases fail. Each layer is independently load-bearing.

[Lightheartdevs]

This fixes the original no-jq secret leak finding: the branch now has a Python fallback for schema secret keys, and if neither jq nor python3 is available it over-masks user/email keys so N8N_USER and LANGFUSE_INIT_USER_EMAIL do not print in the clear.

Local proof:

• tests/test-dream-config-secret-mask.sh passed 7/7 locally.
• bash -n passed for the touched shell scripts.

Still not merge-ready because the branch is stale/dirty against current main:

• A local merge simulation conflicts in dream-server/Makefile and dream-server/dream-cli.
• The test emits some Git Bash symlink cleanup noise locally after reporting success; worth cleaning if it also shows up in CI logs, but the blocking item is the rebase/conflict resolution.

Please rebase onto current main. After that, this looks like a useful security hardening PR.