v1.19.0 adds a new fnox reencrypt command 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 where fnox set -k would skip prompting for the secret value.
Added
fnox reencrypt subcommand (#365) -- @jdx
Previously, re-encrypting secrets after changing recipients required a tedious manual loop of fnox get and fnox set for each secret. The new fnox reencrypt command 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.
# Re-encrypt all age secrets
fnox reencrypt -p age
# Preview what would be re-encrypted
fnox reencrypt -p age --dry-run
# Re-encrypt specific keys
fnox reencrypt MY_SECRET OTHER_SECRET
# Filter by regex pattern
fnox reencrypt --filter "^DB_"
# Skip the confirmation prompt
fnox reencrypt -p age -fThe 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 -k now correctly prompts for the secret value (#367) -- @jdx
When using the -k / --key-name flag with fnox 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 -k works as expected: the secret value is read from stdin, a command-line argument, or an interactive prompt, and is properly encrypted and stored.
# These now work correctly
echo "my-secret" | fnox set -p age -k custom-key-name MY_SECRET
fnox set -p age -k custom-key-name MY_SECRET "my-secret"Full Changelog: v1.18.0...v1.19.0