fix(helm): preserve trailing newlines in literal decryption to prevent double-escaping commas#753
Conversation
…t double-escaping commas Fixes jkroepke#752 Shell command substitution strips trailing newlines, causing decrypted_literal to differ from literal when the value ends with \n. The else branch then incorrectly applies sed comma-escaping. Fix: use printf sentinel idiom to preserve trailing newlines. Signed-off-by: Sudheer Obbu <[email protected]>
|
Fixed the CI failures in the latest commit:
|
…y propagate decryption errors
|
Fixed the remaining 7 test failures in the latest commit. Root cause: The sentinel Fix: Capture the backend exit code before appending the sentinel, then propagate it out of the subshell via |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #753 +/- ##
==========================================
- Coverage 87.00% 86.71% -0.30%
==========================================
Files 22 22
Lines 862 873 +11
==========================================
+ Hits 750 757 +7
- Misses 112 116 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@jkroepke — gentle ping on this PR. It fixes double-escaping of commas in Helm values when the decrypted secret ends with a trailing newline — a subtle bug where the sentinel-based literal decryption was stripping the newline before the |
|
@jkroepke — gentle ping! All 21 CI checks are green and the branch merges cleanly. This fixes the double-escaping of commas when a decrypted literal value ends with a trailing newline (closes #752). The fix uses the standard sentinel idiom to preserve trailing newlines through command substitution. Happy to adjust anything. 🙏 |
Problem
Fixes #752
When
HELM_SECRETS_WRAPPER_ENABLED=trueand a literal secret value ends with a trailing newline, the value is incorrectly double-escaped before being passed to Helm.Root cause: Shell command substitution (
$(...)) always strips trailing newlines from output. Inscripts/commands/helm.sh,decrypted_literal=$(backend_decrypt_literal "${literal}")silently drops any trailing\n. The subsequent equality check[ "${decrypted_literal}" = "${literal}" ]then fails — becauseliteralstill has the newline — causing theelsebranch to fire and applysedcomma-escaping to a value that should pass through unchanged. This double-escapes any commas in the value.This particularly affects ArgoCD integration where multi-line Helm parameters naturally include trailing newlines.
Fix
Use the standard shell
printfsentinel idiom to preserve trailing newlines through command substitution:Appending
printf xinside the subshell prevents the shell from stripping anything (output no longer ends with\n).${decrypted_literal%x}then removes only the sentinel.Also strips a single trailing newline from
literalbefore the comparison (literal_stripped="${literal%$'\n'}") so the check is symmetric regardless of how the encrypted value was stored.The
elsesed-escaping branch is left unchanged — it is only reached when genuine decryption occurred, where comma-escaping is correct.Testing
Manually verified with a literal value ending in
\ncontaining a comma — previously produced\,, now passes through correctly.