Skip to content

Suppress warning-stream ANSI output contaminating strongbox get's stdout - #20

Merged
jpol34 merged 1 commit into
mainfrom
fix-stdout-warning
Sep 16, 2026
Merged

jpol34 merged 1 commit into
mainfrom
fix-stdout-warning

Conversation

@jpol34

@jpol34 jpol34 commented Sep 16, 2026

Copy link
Copy Markdown
Owner

Summary

  • `get`/`reveal --stdout` are documented as piping-safe. In a non-interactive session (no real console - SSH, shell script), PowerShell's warning stream writes ANSI-colored text directly onto stdout instead of staying separate from it.
  • The module's own unapproved-verb warning on import was landing ahead of the actual secret value in every `strongbox get` capture - discovered when a deploy script's `$(strongbox get POSTGRES_USER --real)` captured a corrupted value (an ANSI escape fragment) instead of the real username, which then failed the Postgres role lookup.
  • Set `$WarningPreference = 'SilentlyContinue'` for the whole CLI rather than only suppressing this one known warning, since any future warning anywhere in the script's execution would hit the same contamination.

Test plan

  • 43/43 Pester tests pass
  • Confirmed on the actual Pi (arm64, real deployment target): `strongbox get POSTGRES_USER --real` now returns exactly the expected bytes (verified via `od -c`), no leading escape sequence

🤖 Generated with Claude Code

https://claude.ai/code/session_01WGra6GqN8qAxEDHbhmJwP2

get/reveal --stdout are documented as piping-safe ("Print a secret's value to
stdout, for scripting/piping"). Discovered during real-world use (a deploy
script capturing `strongbox get POSTGRES_USER --real` via shell command
substitution) that PowerShell's warning stream writes ANSI-colored text
directly onto stdout in a non-interactive session (no real console attached -
invoked over SSH or from a shell script), rather than staying separate from
it. The module's own unapproved-verb warning on import was landing ahead of
the actual secret value in every capture, corrupting it (e.g. a captured
POSTGRES_USER became the literal ANSI escape fragment instead of the real
username, which then failed Postgres role lookup).

Set $WarningPreference = 'SilentlyContinue' for the whole CLI rather than
only suppressing the one known warning at import time, since any future
warning anywhere in this script's execution would hit the same
contamination.

Verified: 43/43 Pester tests still pass; confirmed on the actual Pi that
`strongbox get POSTGRES_USER --real` now returns exactly the expected bytes
with no leading escape sequence.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WGra6GqN8qAxEDHbhmJwP2
@jpol34
jpol34 merged commit 4a6555c into main Sep 16, 2026
1 check passed
jpol34 added a commit that referenced this pull request Sep 16, 2026
#21)

Follow-up to #20: that fix set \$WarningPreference = 'SilentlyContinue' for
every invocation, which also silences legitimate warnings for a human typing
at a real terminal - the contamination bug it fixes only manifests when
stdout is redirected (SSH, a shell script), not interactively. Moved
Test-InteractiveTerminal earlier in the file (was only defined later, for
Assert-RevealAllowed) and gated the suppression on it, matching the same
interactive/non-interactive distinction --real already draws. Also reworded
the comment to state the current invariant instead of narrating the bug's
history, per doc-comment discipline.

Verified: 43/43 Pester tests pass; confirmed on the Pi that
`strongbox get POSTGRES_USER --real` still returns clean bytes non-interactively.


Claude-Session: https://claude.ai/code/session_01WGra6GqN8qAxEDHbhmJwP2

Co-authored-by: jpol34 <jpol34@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
@jpol34
jpol34 deleted the fix-stdout-warning branch September 16, 2026 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant