The runner masks secrets per log line, so a multi-line PEM key passed as private_key isn't matched and shows up in plain text in the step's env: block in the log. This leaked the dev deploy key in the Upload image + compose file to /opt/analytics step of the analytics-server deploy-dev workflow.
Change
private_key can now be a single-line base64-encoded key (base64 -w0 <keyfile>), which the runner masks like any other secret. It's decoded into the temp key file before use.
Values containing -----BEGIN are still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).
Updated the input description.
Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
Rollout
Merge this (and the matching change in ssh-command) before switching DEV_SSH_PRIVATE_KEY to the base64 value, since the current main would write the base64 string out verbatim.
## Problem
The runner masks secrets per log line, so a multi-line PEM key passed as `private_key` isn't matched and shows up in plain text in the step's `env:` block in the log. This leaked the dev deploy key in the `Upload image + compose file to /opt/analytics` step of the analytics-server `deploy-dev` workflow.
## Change
- `private_key` can now be a single-line base64-encoded key (`base64 -w0 <keyfile>`), which the runner masks like any other secret. It's decoded into the temp key file before use.
- Values containing `-----BEGIN` are still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).
- Updated the input description.
Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
## Rollout
Merge this (and the matching change in `ssh-command`) before switching `DEV_SSH_PRIVATE_KEY` to the base64 value, since the current `main` would write the base64 string out verbatim.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Multi-line secrets aren't masked by the runner, so a raw PEM key passed
as private_key ends up in plain text in the step's env block in the log.
Accept a single-line base64-encoded key instead, which is masked like
any other secret. Raw PEM keys still work for backwards compatibility.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The runner masks secrets per log line, so a multi-line PEM key passed as
private_keyisn't matched and shows up in plain text in the step'senv:block in the log. This leaked the dev deploy key in theUpload image + compose file to /opt/analyticsstep of the analytics-serverdeploy-devworkflow.Change
private_keycan now be a single-line base64-encoded key (base64 -w0 <keyfile>), which the runner masks like any other secret. It's decoded into the temp key file before use.-----BEGINare still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
Rollout
Merge this (and the matching change in
ssh-command) before switchingDEV_SSH_PRIVATE_KEYto the base64 value, since the currentmainwould write the base64 string out verbatim.🤖 Generated with Claude Code