[renovate]

This PR contains the following updates:

Package	Type	Update	Change
fnox	tools	minor	1.36.0 → v1.43.0

---

Release Notes

jdx/fnox (fnox)

v1.43.0: : Proxy sandbox and egress hardening, exec output redaction, and new lease backends

Compare Source

fnox 1.43.0 makes fnox proxy run harder to misuse: it now has an OS sandbox, a per-session password and blocking of private network destinations. It also adds output redaction and secret filtering to fnox exec, four new lease backends, a local audit log, value-based secret scanning, generated secrets and KeePass field references. Some proxy setups need a config change; see Breaking Changes.

Highlights

• Credential proxy: the proxy can now confine the command it runs, refuses unauthenticated clients and private network destinations, and can inject secrets into query parameters on wildcard domains.
• Keeping secrets out of logs and repos: fnox exec can redact secret values from piped output, fnox scan can search for your actual secret values (including in a pre-commit hook), and an opt-in audit log records which secrets were read, without recording their values.
• Leases: new OAuth2, GitLab, Tailscale and Kubernetes backends, plus easier revocation and JSON listing.

Added

Proxy

• fnox proxy run --sandbox (#​1039) by @​jdx. Runs the command in an OS sandbox where the proxy is the only network access. Inside the sandbox, the command can't read fnox config, state and data dirs, fnox.toml/profile files and their imports, age key files, or common credential dirs (~/.ssh, ~/.aws, ~/.kube, ~/.gnupg, ...). On Linux it also can't reach local credential sockets. It can write only to the working directory and temp files, and it can't create or change .git/hooks, .git/config or fnox config files. The rest of the filesystem stays readable: fnox hides only the paths on its list.

  [proxy]
  sandbox = true                          # project default; --no-sandbox overrides it for one run
  sandbox_allow_write = ["~/.cache"]
  sandbox_deny_read   = ["~/.config/x"]
  sandbox_allow_read  = ["fnox.toml"]

  On Linux this requires bwrap; on macOS fnox uses sandbox-exec. Windows isn't supported. If the sandbox can't start, fnox stops before resolving any secrets and never runs the command unsandboxed. The macOS path hasn't been tested on real hardware yet. On macOS the sandbox can't hide other processes or the Keychain service.
• Query-parameter injection and wildcard domains (#​1026) by @​jdx. A proxy rule can set query = "<name>" instead of header to substitute a secret into a URL query parameter. The value is percent-encoded, and fnox refuses the request (403) if the placeholder appears anywhere else or more than once. domain accepts a leading *. that matches exactly one subdomain level. The apex domain and deeper subdomains don't match, and patterns like *.com are rejected. header is now optional and still defaults to authorization.

  [[proxy.rules]]
  secret = "MAPS_KEY"
  domain = "*.maps.example.com"
  query = "key"
  methods = ["GET"]

• allow_domains and allow_private (#​1038) by @​jdx. allow_domains lets the proxy tunnel the hosts you list without inspection or credentials while egress stays strict. allow_private lists the internal networks the proxy may reach (see Breaking Changes). The proxy audit output now also logs refused request lines with the destination and the reason.

Exec

• Redact secrets from piped output (#​1028) by @​jdx. With fnox exec --redact, secret values in the command's stdout and stderr are replaced with [REDACTED], but only for streams that are piped or redirected; terminal output is left alone. Redaction is off by default. To turn it on everywhere, set redact_exec = true in fnox.toml or FNOX_EXEC_REDACT=1. --no-redact turns it off for one run, and the flag takes precedence over the environment variable, which takes precedence over config. Values shorter than 3 characters aren't redacted, and you can't combine --redact with --replace. Redaction matches exact values only, so it won't catch a secret that has been encoded or split before printing.

  fnox exec --redact -- sh -c 'echo "token=$API_TOKEN"' | cat
  # token=[REDACTED]

• --only and --except (#​1030) by @​jdx. These flags limit fnox exec to the secrets you select. Unselected secrets are never resolved, so their providers aren't called and can't prompt for login or fail the run. Patterns are exact names or case-sensitive globs, and you can repeat the flag or separate patterns with commas. fnox still resolves the secrets a selected secret depends on, but passes them to the command only if they're selected too. Leases follow the same filter. An unknown name, or an --only glob that matches nothing, is an error.

  fnox exec --only DATABASE_URL,'AWS_*' -- ./migrate.sh
  fnox exec --except LEGACY_API_KEY -- npm start

Leases

• OAuth2, GitLab, Tailscale and Kubernetes backends (#​1037) by @​jdx:

  • oauth2-client-credentials: access tokens from any OAuth2 token endpoint. They're revoked only if you set revocation_url.
  • gitlab: project or group access tokens on gitlab.com or self-hosted GitLab, deleted on revoke. GitLab expiry is date-only, so a token can stay valid for up to a day after its lease ends unless you revoke it.
  • tailscale: tagged, ephemeral, pre-authorized auth keys. With the default reusable = false, every command gets a new key and fnox doesn't cache it.
  • kubernetes: ServiceAccount tokens from the TokenRequest API, without needing kubectl. These can't be revoked and expire on their own. The minimum duration is 10 minutes.

  Credential URLs must use https; plain http is accepted only for localhost. fnox lease revoke and fnox lease cleanup now load the parent credentials a backend needs to revoke a lease, so revocation also works when the parent token is stored in [secrets].

  [leases.gl]
  type = "gitlab"
  project = "platform/api"
  scopes = ["read_api"]
  duration = "1h"

• Easier lease revocation and JSON listing (#​1036) by @​jdx. fnox lease revoke accepts a full lease ID, a unique ID prefix (including the shortened ID that lease list prints) or a backend name, which revokes all of that backend's active leases. --all revokes every active lease in the project. If a prefix matches more than one lease, fnox lists the matches and revokes nothing. fnox lease list gains a LABEL column and a --json flag that prints full IDs and timestamps but never cached credentials.

  fnox lease revoke aws-1a2b3c
  fnox lease revoke aws
  fnox lease revoke --all
  fnox lease list --json --active

Other additions

• Local access audit log (#​1031) by @​jdx. The log is opt-in. Each time a secret is read, fnox appends a JSON line to a 0600 file with the time, command, profile, config file, secret name, provider and whether the value came from the daemon cache. Values and command lines are never recorded. The log covers exec, get, export, env --json, list --values, check, shell integration, mcp, proxy run and the TUI. It doesn't cover lease, sync, edit or reencrypt. Use fnox audit to view entries, with --secret, --command, --provider, -n/--limit, --json and --path. FNOX_AUDIT=on|off and FNOX_AUDIT_PATH override the config. Any process running as your user can edit the log, so it isn't tamper-proof. Set [audit] in your global config so a project fnox.toml can't choose the log path.

  # ~/.config/fnox/config.toml
  [audit]
  enabled = true

• Find real secret values with fnox scan (#​1029) by @​jdx. fnox scan --values resolves the active profile and searches for the actual secret values instead of text that merely looks like a secret, so every match is a real leak. Output names the secret but never prints its value. --staged scans what's staged in the git index. --install-hook adds a pre-commit hook that runs fnox scan --values --staged. It won't overwrite an existing hook unless you pass --append. fnox skips secrets shorter than 8 characters, binary files, files over 5 MiB and gitignored files (unless you pass --include-ignored). If fnox.toml itself contains plain values, it will match; use --ignore fnox.toml if that's intended.
• Generate secret values with fnox set --generate (#​1032) by @​jdx. fnox creates the value with the OS random number generator and stores it through the selected provider. --generate-type can be password (the default), hex, base64 (URL-safe) or uuid. --length defaults to 32 and accepts 1 to 4096. fnox doesn't print the value unless you pass --show, and it won't replace an existing secret without --force.

  fnox set API_TOKEN --generate
  fnox set SESSION_KEY --generate --generate-type hex --length 64

• KeePass field references and custom fields (#​1022, #​1025) by @​jdx. The keepass provider now resolves {REF:...} references such as {REF:P@I:<uuid>} instead of returning the raw text. References can be embedded in longer strings and nested up to 10 levels deep. A path such as work/github/ApiToken can now read a custom field (ApiToken) of an entry (work/github). If an entry is titled with the full path, that entry takes precedence. Custom field names are case-sensitive. fnox set doesn't write custom fields.

Changed

• FIDO2 prompts match how the key verifies you (#​1027) by @​jdx. Instead of always asking for an optional PIN, fnox checks whether the key uses a fingerprint, a PIN or touch only, and prompts to match. If a fingerprint read fails in a terminal, fnox offers the PIN as a fallback. fnox provider add asks for a PIN only if the key has one. If a PIN-protected key is used without a terminal, the error now suggests pin = { secret = "NAME" }.

Fixed

• Multiple daemons when TMPDIR changes (#​1042) by @​jdx. When XDG_RUNTIME_DIR was unset, fnox put the daemon socket under $TMPDIR. Tools that set their own TMPDIR (nix-shell, build systems, CI runners, agents) each started a separate daemon. The fallback no longer uses TMPDIR: sockets go to /tmp/fnox-<uid>/fnox, or to the per-user temp directory on macOS. Set FNOX_DAEMON_SOCKET_DIR to an absolute path to choose the directory yourself; it takes precedence over XDG_RUNTIME_DIR. Fixes #​1041.
• fnox edit saving secrets in plaintext (#​1034) by @​jdx. If a secret's provider was defined in an imported config, fnox edit wrote the edited value back as plaintext but still reported that it had re-encrypted secrets. Edits are now re-encrypted with providers from imported configs. If a required provider is missing, fnox edit now fails instead of saving plaintext. Fixes #​1033.

Breaking Changes

• Proxy rules for private networks need allow_private (#​1038). fnox proxy run now refuses loopback, private, link-local (including the cloud metadata endpoint 169.254.169.254), CGNAT and other reserved addresses. This applies to rules, allow_domains and egress = "permissive". fnox checks every address a hostname resolves to. Requests to a host that resolves to one of these addresses, such as an internal API on 10.x, now get 403 destination resolves to a non-public address. To allow them, list the networks:

  [proxy]
  allow_private = ["10.20.0.0/16", "192.168.1.5"]

• Proxy clients must send the session password (#​1038). Each proxy run creates a random password and includes it as the user credentials (user fnox) in the HTTPS_PROXY URL it gives the command. curl, wget, Node, Python, Go and git all send it automatically. A client that removes credentials from proxy URLs gets 407 Proxy Authentication Required. The password keeps out other users on a shared host, but not other processes running as you.
• Daemon socket location (#​1042). If XDG_RUNTIME_DIR isn't set, fnox won't reuse daemons started at the old TMPDIR-based path; they exit after their idle_timeout. Separately, the daemon protocol version is now 7 (#​1031), so a daemon started by an older fnox is replaced on the next read that uses the daemon. Neither change needs action. If you use the fnox_client crate and build RuntimeEnv by hand, add socket_dir: None.

Full Changelog: jdx/fnox@v1.42.1...v1.43.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.

v1.42.1: : Shell hooks survive mise upgrades and work with starship in PowerShell

Compare Source

fnox 1.42.1 fixes two shell-integration problems: hooks that broke after a mise upgrade, and PowerShell hooks that didn't work correctly alongside starship.

Fixed

• Shell hooks breaking after a mise upgrade (#​1016) by @​jdx. fnox activate used to put the fully resolved binary path, such as .../installs/fnox/1.42.0/fnox, into the shell hook. When mise upgrade deleted that directory, every prompt printed _fnox_hook: no such file or directory, and fnox deactivate failed too. These changes apply:
  • fnox now writes the path you ran it from into the hook, keeping symlinks. To get hooks that keep working after upgrades, activate through a stable path:

    eval "$(~/.local/share/mise/installs/fnox/latest/fnox activate zsh)"

    A plain eval "$(fnox activate zsh)" that finds fnox through a versioned PATH entry still writes that versioned path into the hook.
  • In bash, zsh and fish, fnox deactivate now removes the hooks and the fnox function even if the binary is gone. To recover, run fnox deactivate and then activate again. When you activate again, fnox still unsets the secrets that were loaded before.
  • Binary paths in the generated bash, zsh and fish hooks are now quoted, so paths containing spaces work.
  • Nushell and PowerShell hooks still use the old behavior.
• PowerShell hooks with starship (#​1020) by @​jdx. fnox activate pwsh now works whether it's loaded before or after starship:
  • If fnox loaded first, starship replaced the prompt function and cd stopped loading and unloading secrets. The hook now also runs when the current location changes. It passes the event on to any existing handler, and fnox deactivate puts the previous handler back.
  • If starship loaded first, the prompt showed failed commands as successful. The hook now keeps $? and $LASTEXITCODE intact.
  • Each change summary (for example fnox: +1 KEY) is now printed once instead of twice.

Full Changelog: jdx/fnox@v1.42.0...v1.42.1

💚 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.

v1.42.0: : Export selected secrets by name, managed identity for azure-token leases

Compare Source

In fnox 1.42.0, fnox export can export only the secrets you name, and the azure-token lease can authenticate with an Azure managed identity. This release also fixes the AWS SSO login prompt for templated profiles, stops fnox sync --local-file from deleting personal secrets, and updates the bundled TLS root certificates after the eMudhra CA compromise.

Added

• Export only named secrets (#​1002) by @​jdx. fnox export now takes optional KEY arguments. When you pass keys, fnox resolves and exports only those secrets, so it doesn't need to authenticate to providers for the rest of the profile. It still resolves the secrets they depend on for interpolation, but doesn't export them. A named key is exported whatever its env setting, so you don't need --all. An unknown key fails with the same "did you mean" suggestions as fnox get. Format, --output, --dry-run and as_file work the same as before, and running fnox export without keys behaves as it did.

  fnox export API_KEY
  fnox export --format json DATABASE_URL API_KEY

• Managed identity for the azure-token lease (#​1003) by @​jdx. The lease now accepts the same auth and managed_identity_client_id settings as azure-sm, azure-kms and azure-ac. CI jobs on Azure-hosted runners no longer need to install the Azure CLI and run az login --identity just for the lease. You have to turn managed identity on with auth = "managed-identity"; fnox never tries it on its own. Without it, fnox still uses service principal environment variables and then az/azd. In managed identity mode, fnox doesn't check for az on PATH. Setting managed_identity_client_id without auth = "managed-identity", or using an unknown auth value, is a config error.

  [leases.azure-openai-access-token]
  type = "azure-token"
  scope = "https://ai.azure.com/.default"
  env_var = "AI_ACCESS_TOKEN"
  auth = "managed-identity"
  managed_identity_client_id = "00000000-0000-0000-0000-000000000000"  # omit for system-assigned

Fixed

• AWS SSO login prompt with templated or secret-based profiles (#​998) by @​balintant. When profile was a template such as "{{ fnox.profile }}", the aws-kms, aws-ps and aws-sm providers offered to run aws sso login --profile '{{ fnox.profile }}', and that command failed. The prompt now uses the provider's resolved profile, for example aws sso login --profile production. A profile set with profile = { secret = "..." } also gets its resolved name now; before, fnox ran a bare aws sso login. An auth_command you configure still takes precedence.
• fnox sync --local-file deleting personal secrets (#​1004) by @​jdx. When you ran the sync a second time, fnox mistook secrets defined only in fnox.local.toml for cached copies of shared secrets and deleted their source references. Synced entries for these secrets now record local_source = true in their sync block. fnox keeps and refreshes those entries on every sync. Cached copies of shared fnox.toml secrets are still removed when the shared secret is deleted. Existing files work without changes. If this bug already removed one of your secrets, add it back to fnox.local.toml once and it will be kept from then on.
• Revoked eMudhra intermediate certificates (#​1005) by @​jdx. The private keys of eight eMudhra intermediate CA certificates were compromised. fnox now uses rustls-webpki 0.103.16 and webpki-root-certs/webpki-roots 1.0.10, which stop trusting those certificates for HTTPS connections.

Full Changelog: jdx/fnox@v1.41.0...v1.42.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.

v1.41.0: : gopass provider and profile-aware config templates

Compare Source

fnox 1.41.0 adds a gopass provider and lets secret defaults and provider fields use the active profile through Tera templates. fnox exec no longer decrypts env = false secrets that nothing uses, and the AWS SSO login prompt now logs in to the profile your provider is configured with.

Added

• gopass provider (#​980) by @​jdx. Teams that already keep secrets in gopass can now read them through fnox. fnox reads values with gopass cat, writes them with gopass insert -f (fnox set --provider gopass), and tests the connection with gopass ls --flat. The optional mount setting is added to the front of every secret path. fnox removes one trailing newline from each value and leaves other whitespace alone. Errors tell you whether gopass is missing, the GPG key is locked or unavailable, or the secret path doesn't exist. You can also add the provider with fnox provider add <name> gopass.

  [providers]
  gopass = { type = "gopass", mount = "company" }  # mount is optional
  
  [secrets]
  # read with: gopass cat company/apps/myapp/database_url
  DATABASE_URL = { provider = "gopass", value = "apps/myapp/database_url" }

• Profile-aware templates in config (#​993) by @​jdx. A secret default and literal string provider fields are now rendered as Tera templates if they contain {{, {% or {#. Two variables are available: fnox.profile (the selected profile with the highest priority, or default if none is selected) and fnox.profiles (all selected profiles, lowest priority first). This means you can write values that follow the profile, such as AWS profiles or SST stages, once instead of repeating them for every profile. FNOX_PROFILE is still not exported to child processes.

  [providers.aws]
  type = "aws-ps"
  region = "eu-central-1"
  profile = "{{ fnox.profile }}"
  
  [secrets]
  SST_STAGE = { default = "{{ fnox.profile }}" }

  • Templates are rendered before ${NAME} interpolation. A default is only rendered when it's actually used, and only the ${NAME} references left after rendering must exist. So a branch of an {% if %} that isn't taken requires nothing.
  • An undefined variable or a syntax error fails with a message that names the field. To keep a marker as literal text, wrap it in {% raw %}...{% endraw %}.
  • These fields are not templated: value, description, list fields such as age recipients, and credential_command, which keeps its own template context.
  • Check existing configs: a default or provider field that already contains {{, {% or {# as plain text will now be treated as a template. Wrap it in {% raw %} to keep the old value.
• More detailed --help (#​990) by @​jdx. Every public command now shows a description, examples and links to the relevant guides when you run fnox <command> --help. This is the same content as the CLI reference at fnox.jdx.dev/cli. Flags and behavior are unchanged.

Fixed

• fnox exec no longer resolves unused env = false secrets (#​984) by @​andersonkrs. Previously, fnox exec resolved every secret in the profile and then removed the env = false ones from the child's environment. With a PIN-protected age identity, each extra decrypt asked for the PIN again. fnox exec now selects secrets the same way as fnox env --json. It resolves only the secrets it injects plus what they depend on: ${NAME} references in defaults, provider secret references such as token = { secret = ... }, and the inputs of selected leases. If a command lease is selected, it still resolves the whole profile. The aws-sts lease's list of inputs now also includes the environment variables for web identity, container credentials and EC2 instance metadata, so those can still be supplied as env = false secrets. The child's environment is the same as before.
• AWS SSO login prompt uses the provider's profile (#​991) by @​balintant. When authentication fails for an aws-ps, aws-sm or aws-kms provider that sets profile, the default prompt now runs aws sso login --profile <name> instead of a bare aws sso login. Before, the bare command logged in to the default profile and failed if your AWS config had none. The profile is only added when it's a literal value and no auth_command is set. On Windows, it's only added when the name uses ASCII letters, digits, -, _ and ..

Documentation

• The guides, landing page, README, provider pages, lease pages and configuration and environment variable references were reorganized and rewritten (#​987, #​988, #​990) by @​jdx. This fixes some wrong statements, for example: an earlier import takes precedence over a later one, and imports are not recursive. The sync docs now cover TPM PIN protection and hardware-backed service tokens (#​986) by @​andersonkrs.

New Contributors

• @​balintant made their first contribution in #​991

Full Changelog: jdx/fnox@v1.40.0...v1.41.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.

v1.40.0: : Lua plugin providers, Kubernetes Secrets, and Windows daemon support

Compare Source

fnox 1.40.0 adds custom providers written as Lua plugins, a read-only Kubernetes Secrets provider, 1Password Environments, file-backed plain providers and Bitwarden folder scoping. The daemon now runs on Windows. This release also fixes Azure service principal authentication, repeated hardware PIN prompts for age identities, and fnox set dropping piped values.

Added

• Custom providers as Lua plugins (#​968) by @​jdx. You can now write a secrets backend that fnox doesn't support as a Lua 5.4 plugin and share it as a git repository. Declare the plugin under [plugins], then use it with type = "lua":

  [plugins]
  corp = "acme/fnox-plugin-corp#v1.2.0"   # git URL or owner/repo, optional #ref
  
  [providers.corp]
  type = "lua"
  plugin = "corp"                          # or a path such as ./plugins/corp.lua
  
  [secrets]
  DATABASE_URL = { provider = "corp", value = "prod/database-url" }

  • A plugin is a provider.lua that returns hooks. get is required. get_batch, put, encrypt and test are optional, and the hooks you define decide whether fnox set and fnox import can write to the provider. A provider's options table (string values, which can be secret references) is passed to the plugin as ctx.options. Plugins can use the fnox.http, fnox.json, fnox.cmd, fnox.log and fnox.base64 modules. fnox.auth_error(msg) triggers the provider's auth_command flow.
  • New commands: fnox plugin install, update, link, ls and uninstall, plus fnox provider add NAME lua --plugin ....
  • fnox installs a declared plugin the first time a provider uses it (git clone). Plugins go in $FNOX_DATA_DIR/plugins, which defaults to $XDG_DATA_HOME/fnox or ~/.local/share/fnox. Set FNOX_PLUGINS_DIR to use a different location. If a project declares a different source or ref than the installed one, fnox won't load the plugin until you run fnox plugin update <name>.
  • Plugins run with your user's permissions. Only install plugins from sources you trust, and pin a ref. See docs/providers/lua.md for details.
• Kubernetes Secrets provider (#​953) by @​jdx. A read-only kubernetes provider reads existing Secrets through the Kubernetes API. It only makes named GET requests and never lists, watches or writes Secrets. A reference can be secret, secret/key or namespace/secret/key. The optional context, namespace, kubeconfig and prefix settings control where it looks, and the FNOX_K8S_CONTEXT environment variable can also select the context. Daemon caching is always disabled for this provider, even with daemon_cache = true.

  [providers.kubernetes]
  type = "kubernetes"
  context = "production"
  namespace = "payments"
  
  [secrets]
  DATABASE_URL = { provider = "kubernetes", value = "database/url" }

• 1Password Environments (#​955) by @​jdx. The 1password provider can read variables from a 1Password Environment using environment://<environment-id>/<VARIABLE> references. You can mix these with vault item references in the same config. fnox reads each Environment once per provider instance, and a variable missing from the Environment is an error. This needs the beta op CLI with the op environment command.
• Read values from a plaintext file with the plain provider (#​954) by @​joshbode. The new file and format settings make each secret's value a key to look up in that file. format can be env, shell, json, yaml or toml, and you must set it whenever file is set. A relative path resolves against the config file that declares the provider. The file is read-only, and a missing key counts as a missing secret, so default and if_missing still apply.

  [providers.dotenv]
  type = "plain"
  file = "secrets.env"
  format = "env"
  
  [secrets]
  API_TOKEN = { provider = "dotenv", value = "SERVICE_TOKEN" }

• Bitwarden folder scoping (#​965) by @​andersonkrs. The new optional folder setting limits lookups to one Bitwarden folder. For nested folders, use the full path, such as folder = "MyApp/Production". This lets items with the same name exist in different folders. It works with both bw and rbw.
• Azure managed identity (#​964) by @​jdx. azure-sm, azure-kms and azure-ac accept auth = "managed-identity", with an optional managed_identity_client_id for a user-assigned identity. fnox never tries managed identity on its own; you have to set auth.
• Daemon on Windows (#​974) by @​jdx. On Windows, the daemon now uses a per-user named pipe where other platforms use a Unix socket, so Windows gets cached secrets too. Only the current user can access the pipe, and both the client and the daemon check the user on the other end. The wire protocol and the fnox-client API are unchanged.

Fixed

• Azure service principal environment variables (#​964) by @​jdx. Azure providers authenticate as a service principal again when AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET are all set. Without them, fnox falls back to the az/azd login. For sovereign clouds, set AZURE_AUTHORITY_HOST. These variables can also be fnox secrets resolved by fnox exec.
• Hardware PIN prompts for age identities (#​978) by @​andersonkrs and @​jdx. With PIN-protected age identities (age-plugin-tpm --pin, age-plugin-yubikey), a value used by several providers made one command ask for the PIN up to three times. Now a successful decrypt is reused for the rest of the request, so you get one prompt per fnox get, exec or export, or per daemon request. Nothing is kept between requests, and a failed decrypt can be retried.
• fnox set with piped stdin and metadata flags (#​976) by @​jdx. echo val | fnox set A -d "desc" (or with --default or --if-missing) said it worked but saved no value. fnox now stores the piped value along with the metadata. If stdin is empty, only the metadata is updated, as before.

Changed

• fnox import parsing (#​954) by @​joshbode. fnox import now accepts the {secrets, metadata} document that fnox export --format json|yaml|toml produces. The env parser now follows Docker Compose dotenv rules for inline comments. For example, PORT=8080 # default now imports as 8080, where it used to keep the comment as part of the value. # without whitespace before it, as in ID=val#ue, and # inside quotes are still part of the value.

New Contributors

• @​joshbode made their first contribution in #​954
• @​andersonkrs made their first contribution in #​965

Full Changelog: jdx/fnox@v1.39.0...v1.40.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.

v1.39.0: : fnox env --json and a daemon client crate for other tools

Compare Source

fnox 1.39.0 lets other tools, starting with mise, get the same environment that fnox exec would give a command. They can run fnox env --json, or use the new fnox-client crate to read it straight from a running daemon's cache.

Added

• fnox env --json (#​936) by @​jdx. Prints a versioned JSON document describing the environment for a command. It has set (variables), files (as_file contents for the caller to write, so fnox leaves no files behind), remove (variables to unset), missing and leases. Callers apply remove, then set, then files.

  fnox env --json --keys DATABASE_URL,GCP_SA_JSON
  fnox env --json --describe   # list keys and where they can be injected, without resolving anything

  • --for exec (the default) covers env = true and env = "exec" secrets plus leases. --for shell covers only env = true secrets and runs no leases.
  • --keys (repeatable, comma-separated) resolves only the listed keys and the secrets they depend on. env = false secrets are never printed.
  • Errors are also printed as JSON on stdout (config, invalid_keys, resolution) and exit with status 1.
  • --describe never contacts the daemon, creates leases or prompts. With --keys, it checks the keys up front. Its output includes daemon_enabled.
  • Resolution works like fnox exec, using the same daemon cache. The full contract is in docs/reference/env-json.md. --json is required for now.
• fnox-client crate (#​937) by @​jdx. A lightweight Rust library (no tokio, fnox-core or provider SDKs) that lets other programs get the fnox env --json document from a running fnox daemon in one Unix-socket round trip. The client is read-only: it never starts the daemon, stores values or triggers provider calls. On a cache miss, the caller should run fnox env --json itself so prompts and hardware-key touches still work. On Windows, the crate builds but always reports that no daemon is available. fnox-client is published alongside fnox with the same version number. To support it, the daemon protocol moves to v6, and the daemon now refuses requests from projects whose config (or FNOX_DAEMON) does not enable it.

Changed

• Daemon socket path changed (#​937). After you upgrade, the first daemon-enabled command starts a new daemon with an empty cache. The old daemon keeps running until its idle timeout, and fnox daemon clear still reaches it. You don't need to do anything else.
• fnox exec now builds its environment the same way as fnox env --json (#​936). It behaves the same as before, with one exception: it now removes every out-of-scope profile secret from the child's environment, even ones that weren't resolved.

Full Changelog: jdx/fnox@v1.38.1...v1.39.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.

v1.38.1: : Windows release binaries are back

Compare Source

fnox 1.38.1 publishes Windows release binaries again. The v1.37.0 and v1.38.0 releases did not include them.

Fixed

• Windows x64 and ARM64 release archives (#​934) by @​jdx. The Windows release builds for v1.37.0 and v1.38.0 failed while building the bundled OpenSSL, so neither release shipped Windows binaries. The release workflow now builds OpenSSL with the runner's native Perl, and Windows users can download prebuilt binaries again from this release onward. fnox itself has no code changes since v1.38.0.

Full Changelog: jdx/fnox@v1.38.0...v1.38.1

💚 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.

---

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 was generated by Mend Renovate. View the repository job log.