jdx/fnox v1.35.0

v1.35.0: Selective Profile Inheritance

on GitHub

This release introduces selective profile inheritance, letting profiles compose their secrets, providers, and lease backends from other named profiles, alongside a batch of correctness fixes to secret resolution, sync caching, and the background daemon.

Added

• Selective profile inheritance (#770) -- @jdx. Named profiles can now declare an ordered inherits list so their configuration is layered from ancestor profiles before the profile itself, with later entries winning on conflicts. Inheritance applies to secrets, providers, lease backends, and default_provider, and supports nested inheritance. Unknown inherited profiles and inheritance cycles are reported as actionable configuration errors, and inherited fnox.<profile>.toml files are discovered automatically.

  [profiles.openai.secrets]
  OPENAI_API_KEY = { provider = "age", value = "encrypted-key..." }
  
  [profiles.database-local.secrets]
  DATABASE_PASSWORD = { provider = "age", value = "encrypted-password..." }
  
  [profiles.api-local]
  inherits = ["openai", "database-local"]

  fnox -P api-local exec -- ./api

Fixed

• Sync refreshes from current sources, not stale caches (#774) -- @davdroman. fnox sync --local-file could resolve secrets from its previously generated local cache instead of the current source configuration, so changes to a tracked provider or value were ignored on refresh. Cached sync entries are now excluded when resolving refresh sources, stale entries (including inherited profiles and both local override filenames) are removed during full refreshes, and ordinary local overrides, providers, profile inheritance, and --no-defaults behavior are preserved.

• fnox check batches Age secret resolution (#779) -- @davdroman. check previously resolved each secret separately, repeatedly unwrapping the same shared key for batch-encrypted Age values backed by a hardware or plugin identity, which could require one authorization per secret. Eligible Age-backed secrets are now resolved in batches per provider, unwrapping each shared batch key once, while preserving per-secret errors for invalid ciphertexts.

• Background daemon detaches from the client working directory (#795) -- @jdx. Background daemons now start from / instead of inheriting the client's working directory, so the daemon keeps serving requests even after the directory that auto-started it is deleted. Per-request resolution is unchanged, since clients still send their cwd on each request.

• Intentional default fallbacks stay quiet (#771) -- @jdx. When a secret uses if_missing: ignore and falls back from a failed provider to a default (including interpolated defaults), the fallback message is now logged at debug instead of warn. Interpolated default resolution also no longer re-runs the already-failed root provider, while still surfacing genuine interpolation cycle errors.

Performance

• Skip redundant secret reloads on cd (#766) -- @jdx. fnox hook-env no longer forces a full secret reload on every working-directory change. Sessions now refresh only when the effective config hierarchy or relevant FNOX_* environment variables change, so navigating between directories within the same fnox.toml tree preserves the loaded environment.

Documentation

• Docs and CLI help audited against actual behavior (#798) -- @jdx. Every docs page and CLI help string was checked against the code and corrected. Notable fixes include the secret resolution order in how-it-works (provider, then default, then environment), the Bitwarden auth hint (FNOX_BW_SESSION, not FNOX_BW_SESSION_TOKEN), FIDO2/YubiKey setup using a positional type instead of a nonexistent --type flag, http_timeout documented as a duration string, import examples that require --provider and --force, corrected keychain/Linux Secret Service requirements, and README additions for the fido2, yubikey, foks, and keeper-sm providers.

Full Changelog: v1.34.1...v1.35.0

💚 Sponsor fnox

fnox is built and maintained by @jdx, an open source developer at entire.io, the title sponsor of his open source work.

If fnox handles secrets or config for you or your team, please consider becoming an individual or company sponsor. Your support funds ongoing development and helps keep fnox secure, free, and independent.