Conversation
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.
Upstream release
Bumps bundled fnox binary from 1.18.0 to 1.19.0.
Release: https://github.com/jdx/fnox/releases/tag/v1.19.0
Release notes
v1.19.0 adds a new
fnox reencryptcommand that makes it easy to re-encrypt all your secrets when encryption provider configuration changes -- for example, when adding or removing age recipients. This release also fixes a bug wherefnox set -kwould skip prompting for the secret value.Added
fnox reencryptsubcommand (#365) -- @jdxPreviously, re-encrypting secrets after changing recipients required a tedious manual loop of
fnox getandfnox setfor each secret. The newfnox reencryptcommand handles this in one step: it decrypts matching secrets and re-encrypts them with the current provider configuration, writing the updated ciphertext back to the correct source config file.The command correctly handles multi-line secrets, writes back to the original source file (including distinguishing root
[secrets]from[profiles.X.secrets]), clears stale sync caches, and scrubs decrypted plaintext from the process environment after re-encryption. Only secrets backed by encryption-capable providers are eligible.Fixed
fnox set -know correctly prompts for the secret value (#367) -- @jdxWhen using the
-k/--key-nameflag withfnox set, the command incorrectly treated it as a metadata-only operation and skipped prompting for the secret value. It also wrote the key name itself as the stored config value, bypassing the encryption provider entirely. Now-kworks as expected: the secret value is read from stdin, a command-line argument, or an interactive prompt, and is properly encrypted and stored.Full Changelog: jdx/fnox@v1.18.0...v1.19.0