Live rk_live_ workspace key written unmasked to fleet-node logs by startup banner and broker-failure error path

[barryollama]

Summary

Two code paths print a live rk_live_ workspace key unmasked to files that persist on disk. Every other path masks the same value correctly to rk_live_…NNNN.

No key value appears in this issue. Locations and behaviour only.

The two leaking paths

1. The startup banner. On an older banner format, the Workspace Key: field is printed in full. Later banners from the same binary mask correctly to rk_live_…NNNN, so the masking exists and this path simply misses it.
2. The broker-failure error path. When a broker command fails, the error message embeds the full command line, and the key is inside it — unmasked.

Both write to launchd-declared sinks that persist indefinitely:

<relay-root>/fleet-node.stdout.log
<relay-root>/fleet-node.stderr.log

Observed on a fleet node running relay-broker/11.4.0. Both files were still present and still being appended to at the time of writing, so this is not a historical artefact — a restart re-runs the banner path.

Notably, a node running relay-broker/11.3.1 showed no rk_live_ token in its fleet-node.stdout.log, which suggests the banner leak is specific to certain versions or banner formats rather than universal. Worth pinning down which.

Why it matters

• The key is live, not a test credential.
• It is on a shared fleet node, not a single operator's laptop.
• It is at rest on disk, so it outlives the process, survives restarts, and lands in any backup, snapshot or support bundle that captures the relay directory.
• These files are the first thing anyone tails when debugging a node, so the exposure surface is everyone who has ever investigated that host.

There is an existing operational rule on this fleet against running process listings that include argv, precisely because argv leaks live workspace keys and agent tokens. That rule is undermined if the product writes the same value to a log file that nobody thinks to treat as a secret.

Suggested fixes

1. Route every key render through the existing masking helper — including the startup banner and the error-formatting path.
2. Never embed a full command line containing a credential in an error message; redact before formatting, not after.
3. Consider treating fleet-node.*.log as sensitive by default (mode 0600) regardless, since they may capture other secrets the same way.
4. A test that asserts no rk_live_ literal reaches any log sink would catch regressions of all three.

Not covered here

Rotation of the specific exposed credential is being handled separately by its owner and is deliberately out of scope for this issue.