* action: trim sensitive env values before GitHub Actions log masking
GitHub Actions' log masking is line-based: a secret value containing a
newline only registers the first line as a mask, leaving the remainder
exposed verbatim in logs. A trailing newline copied from a terminal into
a GitHub Actions secret (e.g. ANTHROPIC_API_KEY) was enough to leak
"a large part of the key" in run logs (pullfrog/pullfrog#41).
normalizeEnv now trims leading/trailing whitespace from any value whose
key matches the sensitive name pattern, masks the cleaned value, and
warns when whitespace was stripped so the user notices the source.
sanitizeSecret is reused for dbSecrets injection in main.ts. The three
secret-store PUT/POST routes also trim values defensively, matching the
existing name.trim() pattern.
Real multi-line secrets are not used in practice — even GITHUB_PRIVATE_KEY
PEMs are stored single-line with escaped \n and unescaped at the point of
use — so a straight trim() is safe.
* action: address review — use core.setSecret for masking, don't zero whitespace-only
Pullfrog's review of #698 caught two real issues in the original fix:
1. `console.log(\`::add-mask::\${trimmed}\`)` doesn't escape \r/\n. If a
value survives trim with an embedded newline (PEMs, kubeconfigs, JSON),
the runner only registers the first line as a mask and the rest leaks.
`core.setSecret(trimmed)` routes through @actions/core which
percent-encodes \r/\n so the runner V2 parser decodes back to the full
value and registers every non-empty line as a separate mask. Removes
the load-bearing "no embedded newlines" invariant from the fix.
2. Whitespace-only sensitive values silently became "". Downstream
truthy checks would flip from "set" to "missing" with no log. Now
sanitizeSecret returns null in that case and callers skip the
process.env write, surfacing a clear missing-key error instead.
Tests rewritten to assert process.env state directly — no stdout spies.
Masking correctness is delegated to @actions/core (trusted dependency).
Colin McDonnell
d5f881e9fc