fix(set): fall back to current provider when updating secrets by rpendleton · Pull Request #439 · jdx/fnox

rpendleton · 2026-04-25T00:29:35Z

When multiple providers were configured without a default_provider, running fnox set on an existing secret without --provider stored the new value as plaintext while leaving the original provider key in place. Subsequent fnox get calls then failed, since fnox would try to decrypt a value that was no longer encrypted.

Before falling back to default_provider or plaintext, we now reuse the secret's existing provider. This allows updates to stay encrypted and readable without requiring --provider on every call.

greptile-apps · 2026-04-25T00:31:30Z

Greptile Summary

Fixes a bug where fnox set on an existing encrypted secret (without --provider) would overwrite the value as plaintext while leaving the original provider key intact, breaking subsequent fnox get calls. The fix adds a new fallback step that checks the secret's current provider before consulting default_provider or defaulting to plaintext.

The new get_secret helper correctly mirrors the lookup precedence of get_secrets, and the existing provider-write guard (secret_config.provider().is_none()) at line 215 interacts cleanly with the new branch — no double-write or unintended override.

Confidence Score: 5/5

Safe to merge — targeted fix with a clear regression test and no observable behaviour change for callers that already pass --provider.

No P0 or P1 findings. The new get_secret lookup correctly mirrors get_secrets precedence, the borrow-checker-friendly ordering (immutable lookup before mutable write) is sound, and the provider-write guard at line 215 correctly handles both the profile-specific and top-level secret scenarios.

No files require special attention.

Important Files Changed

Filename	Overview
src/commands/set.rs	Adds a new fallback branch that reuses the secret's existing provider when `--provider` is not supplied; correctly placed before the `default_provider` lookup.
src/config.rs	Adds `get_secret` helper that mirrors `get_secrets` precedence (profile-first → top-level fallback, respecting `no_defaults`) without cloning the map.
test/set_no_provider.bats	New bats test exercises the exact bug scenario: two providers configured, no `default_provider`, secret initially set with `--provider provider1`, then updated without `--provider`, verified to round-trip correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[fnox set KEY VALUE] --> B{--provider flag?}
    B -- yes --> C[Use explicit provider]
    B -- no --> D{Existing secret\nhas provider?}
    D -- yes --> E[Reuse existing provider\n🆕 new fallback]
    D -- no --> F{default_provider\nconfigured?}
    F -- yes --> G[Use default provider]
    F -- no --> H[Store as plaintext]
    C & E & G --> I[Encrypt / store with provider]
    H --> J[Store as default value]
    I & J --> K[Save config file]

_{Reviews (3): Last reviewed commit: "perf(config): add get_secret for non-clo..." | Re-trigger Greptile}

gemini-code-assist

Code Review

This pull request updates the set command to automatically reuse a secret's existing provider when updating its value if no provider is explicitly specified. It also adds a comprehensive integration test to ensure this behavior works correctly with multiple providers. A performance concern was raised regarding the inefficient cloning of the secrets map during the provider lookup, suggesting a more direct access method instead.

When multiple providers were configured without a `default_provider`, running `fnox set` on an existing secret without `--provider` stored the new value as plaintext while leaving the original `provider` key in place. Subsequent `fnox get` calls then failed, since fnox would try to decrypt a value that was no longer encrypted. Before falling back to `default_provider` or plaintext, we now reuse the secret's existing provider. This allows updates to stay encrypted and readable without requiring `--provider` on every call. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Avoid cloning the entire secrets map in `set` just to read the existing secret's provider. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

@bglusman

@bglusman

@bglusman

## Upstream release Bumps bundled fnox binary from 1.20.0 to 1.22.0. **Release**: https://github.com/jdx/fnox/releases/tag/v1.22.0 ## Release notes v1.22.0 introduces a top-level library API for embedding fnox in Rust applications, and fixes a sharp edge in `fnox set` that could turn an encrypted secret into plaintext. ## Added **Top-level `Fnox` library API** ([#442](jdx/fnox#442)) -- @bglusman Downstream Rust consumers can now use fnox as a library in three lines instead of replicating the internals of `GetCommand::run`: ```rust use fnox::Fnox; let fnox = Fnox::discover()?; // walks up + merges parent + local + global config let value = fnox.get("MY_KEY").await?; let names = fnox.list()?; ``` The new `Fnox` type lives in `src/library.rs` and is re-exported from the crate root. Highlights: - `Fnox::discover()` mirrors the binary's full config-discovery and merge chain via `Config::load_smart`, including the `FNOX_PROFILE` env var. - `Fnox::open(path)` loads an explicit config without the upward-search/merge behavior. - `Fnox::with_profile("staging")` builder for non-default profiles. - `get()` returns `FnoxError::SecretNotFound` with a populated "Did you mean…" suggestion, matching the CLI's UX so callers don't need to recompute it. - `Fnox` is cheap to clone (`Config` is held behind an `Arc`) and safe to hold across `.await`. `set()` is intentionally not part of this first cut; it'll get its own design pass. ## Fixed **`fnox set` no longer silently downgrades encrypted secrets to plaintext** ([#439](jdx/fnox#439)) -- @rpendleton When multiple providers were configured without a `default_provider`, running `fnox set` on an existing secret without `--provider` would write the new value as plaintext while leaving the original `provider = "..."` key in place. The next `fnox get` then failed trying to "decrypt" a value that was no longer encrypted. `fnox set` now reuses the secret's existing provider before falling back to `default_provider` or plaintext, so updates stay encrypted and readable without having to pass `--provider` on every call: ```bash fnox set --provider age MY_SECRET "original-value" # encrypted with age fnox set MY_SECRET "new-value" # still encrypted with age ``` **Deterministic provider ordering in the generated schema** ([#432](jdx/fnox#432)) -- @jdx Within-category provider ordering in `build/generate_providers.rs` was inheriting `fs::read_dir` order, which is OS- and filesystem-dependent. That non-determinism flowed into `docs/public/schema.json` and caused autofix.ci to keep reshuffling 100+ lines between runs. A secondary sort by provider name fixes the churn; running `fnox schema` twice now produces byte-identical output. **Mobile docs banner layout** ([#437](jdx/fnox#437)) -- @jdx At `<=640px` the announcement banner now switches to a column layout with the close button pinned to the top-right corner, instead of cramming the message and "Read more" link onto one squeezed line. ## Changed - Docs site nav now shows the current release version (read from `Cargo.toml` at build time) and a GitHub star count, matching the mise/aube docs ([#443](jdx/fnox#443)) -- @jdx - Added a dismissible cross-site announcement banner that fetches its config from `jdx.dev/banner.json` and respects the `expires` field ([#434](jdx/fnox#434), [#436](jdx/fnox#436)) -- @jdx ## New Contributors * @bglusman made their first contribution in [#442](jdx/fnox#442) **Full Changelog**: jdx/fnox@v1.21.0...v1.22.0 ## 💚 Sponsor fnox fnox is maintained by [@jdx](https://github.com/jdx) under [**en.dev**](https://en.dev) — a small independent studio building developer tooling like [mise](https://mise.jdx.dev/), [aube](https://aube.en.dev/), hk, and more. Keeping fnox secure, maintained, and free is funded by sponsors. If fnox is handling secrets or config for you or your team, please consider [sponsoring at en.dev](https://en.dev). Sponsorships are what let fnox stay independent and the project keep moving. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

When multiple providers were configured without a `default_provider`, running `fnox set` on an existing secret without `--provider` stored the new value as plaintext while leaving the original `provider` key in place. Subsequent `fnox get` calls then failed, since fnox would try to decrypt a value that was no longer encrypted. Before falling back to `default_provider` or plaintext, we now reuse the secret's existing provider. This allows updates to stay encrypted and readable without requiring `--provider` on every call. --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

@bglusman

@bglusman

gemini-code-assist Bot reviewed Apr 25, 2026

View reviewed changes

Comment thread src/commands/set.rs

rpendleton force-pushed the rpendleton/fallback-to-current-provider-on-set branch from 3acd925 to 018faf1 Compare April 25, 2026 00:45

rpendleton and others added 2 commits April 24, 2026 20:56

perf(config): add get_secret for non-cloning single-key lookup

40830ab

Avoid cloning the entire secrets map in `set` just to read the existing secret's provider. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

rpendleton force-pushed the rpendleton/fallback-to-current-provider-on-set branch from 018faf1 to 40830ab Compare April 25, 2026 02:56

jdx merged commit bf3177b into jdx:main Apr 25, 2026
14 checks passed

mise-en-dev mentioned this pull request Apr 25, 2026

chore: release v1.22.0 #433

Merged

rpendleton deleted the rpendleton/fallback-to-current-provider-on-set branch April 26, 2026 03:57

mise-en-dev mentioned this pull request Apr 26, 2026

chore: release v1.23.0 #445

Merged

BrewTestBot mentioned this pull request Apr 26, 2026

fnox 1.22.0 Homebrew/homebrew-core#279529

Merged

github-actions Bot mentioned this pull request Apr 26, 2026

chore: bump bundled fnox to 1.22.0 fullerzz/fnox-py#10

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(set): fall back to current provider when updating secrets#439

fix(set): fall back to current provider when updating secrets#439
jdx merged 2 commits intojdx:mainfrom
rpendleton:rpendleton/fallback-to-current-provider-on-set

rpendleton commented Apr 25, 2026

Uh oh!

greptile-apps Bot commented Apr 25, 2026 •

edited

Loading

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

rpendleton commented Apr 25, 2026

Uh oh!

greptile-apps Bot commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

greptile-apps Bot commented Apr 25, 2026 •

edited

Loading