{{ message }}
Repository navigation
Make Secrets#key? existence-based so empty values count as present - #1972
Open
Harsh23Kashyap wants to merge 1 commit into
Open
Harsh23Kashyap wants to merge 1 commit into
Harsh23Kashyap wants to merge 1 commit into
Conversation
Secrets#key? used .present? on the fetched value, so a secret that is set but empty (EMPTY=) reported as missing while Secrets#[] returns its empty string. That made the two methods disagree, and broke the ssh key_data check in Kamal::Configuration::Ssh, which falls back to treating the secret name as an inline key when key? is false. Fetch the key and only translate KeyError into false, matching Hash semantics: a key that exists counts as present even when its value is empty. Fixes basecamp#1966
Contributor
There was a problem hiding this comment.
🟢 Approved
The focused change preserves missing-key handling and includes regression coverage, with no unresolved findings.
No open issues 🎉
What changed in this PR
Fixes #1966 by making Kamal::Secrets#key? check existence rather than value presence, consistent with Secrets#[].
Changes:
- Counts empty secrets as present while preserving missing-key behavior.
- Adds regression coverage for empty-value lookups.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
Review effort: Balanced
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Kamal::Secrets#key?fetches the value and calls.present?on it, so a secret that is set but empty (EMPTY=in.kamal/secrets) reports as missing, whileSecrets#[]happily returns its empty string. The two methods disagree about the same key.One place this bites is
Kamal::Configuration::Ssh, which checkssecrets.key?("KAMAL_SSH_PRIVATE_KEY")-style lookups via thekey_datasecret: with an intentionally empty value it falls back to treating the secret name as an inline key (plus a deprecation warning), instead of seeing the key as set.Fixes #1966.
Fix
Fetch the key and translate only
KeyErrorintofalse, matching Hash semantics: a key that exists counts as present even when its value is empty.#[]keeps raising for genuinely missing keys and still returns empty strings, so legitimately empty values keep working.Verification
Repro with a
.kamal/secretsfile containingEMPTY=:Before:
After:
Added a regression test covering the empty-value case.
bin/test test/secrets_test.rbpasses: 15 runs, 29 assertions, 0 failures (ran twice). The fullbin/testrun shows the same 4 failures and 23 errors before and after this change; they are pre-existing on unmodified main in my environment (docker-dependent CLI tests) and are untouched by this patch.