chore(deps): update dependency fnox to v1.25.1 #1

Merged

rosa merged 1 commit from renovate/fnox-1.x into main

2026-05-27 16:10:19 +00:00

rosa commented

2026-05-27 15:55:12 +00:00

Owner

This PR contains the following updates:

Package	Update	Change
fnox	patch	`1.25.0` → `1.25.1`

Release Notes

jdx/fnox (fnox)

`v1.25.1`: : Keychain reliability and dependency refreshes

Compare Source

A patch release focused on the OS keychain provider: a deadlock and dialog-storm fix on macOS, plus a clean migration to keyring-core v1 and keepass 0.12.

Fixed

Keychain provider no longer deadlocks the runtime or stacks dialogs (#495) -- @jdx

Resolving several keychain-backed secrets at once on macOS could hang fnox indefinitely (see discussion #489). The default batch path fans out 10 concurrent reads, which surfaced up to 10 overlapping "Always Allow / Allow / Deny" Security dialogs and pinned every tokio worker thread waiting for the user — deadlocking the runtime.

Two changes fix this:

All keyring-core calls (set_password, get_password, delete_credential) now run via tokio::task::spawn_blocking, so a blocked Security dialog never pins a runtime worker.
The keychain provider overrides get_secrets_batch to resolve entries serially, so dialogs appear one at a time and Ctrl-C stays responsive.

fnox set against the keychain and test_connection are routed through the blocking pool too.

KeePass provider works with keepass 0.12 (#494) -- @jdx

The 0.10 → 0.12 bump made Group.groups, Group.entries, Database.root, and friends pub(crate), with access now going through Database::root(), GroupRef/GroupMut accessors, and add_group / add_entry. The provider has been rewritten to match:

Entry lookup returns an EntryId and resolves to EntryRef / EntryMut via Database::entry / entry_mut, avoiding lifetime issues with recursive GroupRef borrows.
Writes navigate and create groups segment-by-segment via group_mut / add_group, then update or add_entry.
Field writes use the new set_protected / set_unprotected helpers, preserving "Password protected, everything else unprotected" behavior.

Lookup semantics are unchanged: path segments before the last name exact-named subgroups; the final segment is searched recursively by entry title.

Changed

Migrate from keyring v3 to keyring-core v1 (#493) -- @jdx

Upstream keyring v4 is now just a CLI/sample app — the library moved to keyring-core plus per-platform credential-store crates. fnox now depends on:

apple-native-keyring-store (with the keychain feature) on macOS
windows-native-keyring-store on Windows
dbus-secret-service-keyring-store (with crypto-rust + vendored) on Linux

A new fnox_core::keyring_store::init() lazily registers the default store once per process; both the keychain provider and the github_oauth lease backend invoke it before constructing an Entry. Error classification now matches keyring_core::Error::{NoEntry, NoStorageAccess(_)} enum variants instead of string-matching error messages, producing more accurate ProviderSecretNotFound vs ProviderAuthFailed errors.

No config or CLI surface changes — the keychain provider and github_oauth lease backend keep the same TOML fields and behavior.

Documentation

Use the keychain for a bootstrap key, not bulk storage (#495) -- @jdx

The keychain provider docs now recommend storing a single age identity in the OS keychain and encrypting the rest of your secrets with the age provider, so you hit one "Always Allow" prompt instead of one per secret:

[providers]
keychain = { type = "keychain", service = "fnox" }
age      = { type = "age", recipients = ["age1..."], identity = { provider = "keychain", value = "age-key" } }

[secrets]
DATABASE_URL = { provider = "age", value = "encrypted..." }
API_KEY      = { provider = "age", value = "encrypted..." }
STRIPE_KEY   = { provider = "age", value = "encrypted..." }

Reach for provider = "keychain" directly only for the handful of bootstrap secrets that have nothing else to decrypt them.

Full Changelog: https://github.com/jdx/fnox/compare/v1.25.0...v1.25.1

fnox is maintained by @jdx under en.dev — a small independent studio building developer tooling like mise, aube, 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. Sponsorships are what let fnox stay independent and the project keep moving.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [fnox](https://github.com/jdx/fnox) | patch | `1.25.0` → `1.25.1` | --- ### Release Notes <details> <summary>jdx/fnox (fnox)</summary> ### [`v1.25.1`](https://github.com/jdx/fnox/releases/tag/v1.25.1): : Keychain reliability and dependency refreshes [Compare Source](https://github.com/jdx/fnox/compare/v1.25.0...v1.25.1) A patch release focused on the OS keychain provider: a deadlock and dialog-storm fix on macOS, plus a clean migration to `keyring-core` v1 and `keepass` 0.12. #### Fixed **Keychain provider no longer deadlocks the runtime or stacks dialogs** ([#495](https://github.com/jdx/fnox/pull/495)) -- [@jdx](https://github.com/jdx) Resolving several keychain-backed secrets at once on macOS could hang fnox indefinitely (see [discussion #489](https://github.com/jdx/fnox/discussions/489)). The default batch path fans out 10 concurrent reads, which surfaced up to 10 overlapping "Always Allow / Allow / Deny" Security dialogs and pinned every tokio worker thread waiting for the user — deadlocking the runtime. Two changes fix this: - All `keyring-core` calls (`set_password`, `get_password`, `delete_credential`) now run via `tokio::task::spawn_blocking`, so a blocked Security dialog never pins a runtime worker. - The keychain provider overrides `get_secrets_batch` to resolve entries **serially**, so dialogs appear one at a time and Ctrl-C stays responsive. `fnox set` against the keychain and `test_connection` are routed through the blocking pool too. **KeePass provider works with `keepass` 0.12** ([#494](https://github.com/jdx/fnox/pull/494)) -- [@jdx](https://github.com/jdx) The 0.10 → 0.12 bump made `Group.groups`, `Group.entries`, `Database.root`, and friends `pub(crate)`, with access now going through `Database::root()`, `GroupRef`/`GroupMut` accessors, and `add_group` / `add_entry`. The provider has been rewritten to match: - Entry lookup returns an `EntryId` and resolves to `EntryRef` / `EntryMut` via `Database::entry` / `entry_mut`, avoiding lifetime issues with recursive `GroupRef` borrows. - Writes navigate and create groups segment-by-segment via `group_mut` / `add_group`, then update or `add_entry`. - Field writes use the new `set_protected` / `set_unprotected` helpers, preserving "Password protected, everything else unprotected" behavior. Lookup semantics are unchanged: path segments before the last name exact-named subgroups; the final segment is searched recursively by entry title. #### Changed **Migrate from `keyring` v3 to `keyring-core` v1** ([#493](https://github.com/jdx/fnox/pull/493)) -- [@jdx](https://github.com/jdx) Upstream `keyring` v4 is now just a CLI/sample app — the library moved to `keyring-core` plus per-platform credential-store crates. fnox now depends on: - `apple-native-keyring-store` (with the `keychain` feature) on macOS - `windows-native-keyring-store` on Windows - `dbus-secret-service-keyring-store` (with `crypto-rust` + `vendored`) on Linux A new `fnox_core::keyring_store::init()` lazily registers the default store once per process; both the `keychain` provider and the `github_oauth` lease backend invoke it before constructing an `Entry`. Error classification now matches `keyring_core::Error::{NoEntry, NoStorageAccess(_)}` enum variants instead of string-matching error messages, producing more accurate `ProviderSecretNotFound` vs `ProviderAuthFailed` errors. No config or CLI surface changes — the `keychain` provider and `github_oauth` lease backend keep the same TOML fields and behavior. #### Documentation **Use the keychain for a bootstrap key, not bulk storage** ([#495](https://github.com/jdx/fnox/pull/495)) -- [@jdx](https://github.com/jdx) The [keychain provider docs](https://fnox.jdx.dev/providers/keychain) now recommend storing a single age identity in the OS keychain and encrypting the rest of your secrets with the `age` provider, so you hit one "Always Allow" prompt instead of one per secret: ```toml [providers] keychain = { type = "keychain", service = "fnox" } age = { type = "age", recipients = ["age1..."], identity = { provider = "keychain", value = "age-key" } } [secrets] DATABASE_URL = { provider = "age", value = "encrypted..." } API_KEY = { provider = "age", value = "encrypted..." } STRIPE_KEY = { provider = "age", value = "encrypted..." } ``` Reach for `provider = "keychain"` directly only for the handful of bootstrap secrets that have nothing else to decrypt them. **Full Changelog**: <https://github.com/jdx/fnox/compare/v1.25.0...v1.25.1> #### 💚 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. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

rosa added 1 commit

2026-05-27 15:55:12 +00:00