|
| 1 | +- Purpose of this page |
| 2 | + - Highlight **capabilities that show up in one tool’s public story but not the other’s**, so you can scan for gaps instead of reading two parallel product pitches. Provider catalogs change; treat bullets as **“documented on the official site when this note was written”**, then verify in each project’s current docs. [^1] [^2] |
| 3 | +- ## Features emphasized for **fnox** but not for **[[secretspec]]** |
| 4 | + - **Encrypt-to-git in the project file** |
| 5 | + - **fnox** documents storing **encrypted ciphertext** (or KMS-style encrypted payloads) **inside `fnox.toml`** that you commit—for example via **age** (including SSH-key flows) or **AWS / Azure / GCP KMS**—so teammates clone **values-in-repo** without plaintext in history. [^1] |
| 6 | + - **[[secretspec]]**’s public positioning is the opposite: **`secretspec.toml` declares requirements only**; it should **not** carry real secret material, even encrypted—the committed file is the **contract**, not the vault. [^2] |
| 7 | + - **Inline non-provider “plain” defaults in the same repo file** |
| 8 | + - **fnox** documents a **`plain` provider for defaults** (explicitly “for defaults only”) so local dev can ship **cleartext defaults beside** encrypted or remote-backed entries in **`fnox.toml`**. [^1] |
| 9 | + - **[[secretspec]]** steers defaults through **providers** (for example **dotenv**, **keyring**) rather than treating the committed spec as a place for inline secret values. [^2] |
| 10 | + - **Directory-based shell auto-export** |
| 11 | + - **fnox** documents **`fnox activate`** so a shell can **auto-load secrets when you `cd`** into a tree that contains **`fnox.toml`**. [^1] |
| 12 | + - **[[secretspec]]**’s homepage narrative centers on **`secretspec run` / `check` / `set`** style workflows and SDK loading—not an equivalent **“activate my shell on directory entry”** feature in the same first-class way. [^2] |
| 13 | + - **Providers called out on fnox’s landing page but not on SecretSpec’s homepage list** |
| 14 | + - Examples from **fnox** marketing/docs: **AWS Systems Manager Parameter Store (`aws-ps`)**, **Azure Key Vault secrets (`azure-sm`)**, **Bitwarden Secrets Manager**, **Doppler**, **Infisical**, plus the **encrypt-to-git** stack (**age**, **AWS/Azure/GCP KMS**) as a headline cluster. [^1] |
| 15 | + - **[[secretspec]]**’s homepage provider gallery at the time emphasized **keyring**, **dotenv**, **`env` (read-only for CI)**, **`pass`**, **[[1Password]]**, **LastPass**, **GCP Secret Manager**, **AWS Secrets Manager**, **Vault/OpenBao**—a different shape (no **Doppler**, **Infisical**, **Parameter Store**, **Azure** entries, or **age/KMS encrypt-to-git** in that same list). [^2] |
| 16 | +- ## Features emphasized for **[[secretspec]]** but not for **fnox** |
| 17 | + - **Committed file is never a value store (even encrypted)** |
| 18 | + - **[[secretspec]]** repeats that **`secretspec.toml` only declares names, descriptions, required/optional rules, and shapes**—**values always come from providers at runtime**. That is a **design guarantee** in how they describe the system. [^2] |
| 19 | + - **fnox** intentionally supports **ciphertext and plain defaults inside `fnox.toml`**, so it does **not** share that same “spec never holds secrets” invariant. [^1] |
| 20 | + - **First-party in-process Rust SDK with codegen** |
| 21 | + - **[[secretspec]]** documents a **type-safe Rust SDK**: `declare_secrets!` over **`secretspec.toml`**, builder-style `load()`, typed fields, optional secrets as `Option`, helpers like **`set_as_env_vars`**, and invites other language SDKs via contributions. [^2] |
| 22 | + - **fnox**’s landing page is **CLI + TOML + shell integration**-centric; it does **not** advertise a comparable **generated Rust API surface** the same way. [^1] |
| 23 | + - **Built-in cross-provider migration (`import`)** |
| 24 | + - **[[secretspec]]** documents **`secretspec import`** (example flow: import from **`dotenv://.env.production`** into **`keyring://`**) as a first-class way to **move material between backends without changing app code**. [^2] |
| 25 | + - **fnox** docs summarized here do **not** foreground an **`import`-style** “bulk move between providers” command in the same way (you may still accomplish moves manually per provider). [^1] |
| 26 | + - **Secret requirement primitives beyond name + provider** |
| 27 | + - **[[secretspec]]** documents **`as_path`** (materialize to **temporary files** for consumers that need paths), plus **`type` + `generate`** so some secrets can be **auto-created when missing** (for example generated passwords). [^2] |
| 28 | + - **fnox**’s quick examples center on **provider + value/reference**; those **declaration-level** knobs are **not** the headline in the same public comparison surface. [^1] |
| 29 | + - **User-global provider configuration with interactive setup** |
| 30 | + - **[[secretspec]]** shows **`secretspec config init`** writing **`~/.config/secretspec/config.toml`**, interactive provider picking, and **per-secret provider overrides / fallback lists** wired through **named provider aliases** in that config. [^2] |
| 31 | + - **fnox**’s intro emphasizes **project-local `fnox.toml`** and providers declared there; it does **not** mirror that exact **interactive user-wide config wizard + alias layer** in the excerpted homepage material. [^1] |
| 32 | + - **Providers called out on SecretSpec’s homepage but not on fnox’s landing list** |
| 33 | + - Examples: **LastPass**, the dedicated **read-only `env` provider for CI**, and the **dotenv** provider as a first-class “traditional `.env`” backend sit in **[[secretspec]]**’s story. [^2] |
| 34 | + - **fnox** lists **OS keychain**, **`pass`**, cloud managers, etc., but **does not list LastPass, dotenv-as-provider, or a read-only env backend** in the same marketing provider grid. [^1] |
| 35 | +- ## Overlap (intentionally brief) |
| 36 | + - Both offer **multi-environment profiles**, a **TOML project file**, CLI flows to **run subprocesses with secrets injected**, and overlapping remote backends such as **[[1Password]]**, **Vault-class** stores, **GCP/AWS secret managers**, and Unix **`pass`**. Treat this section as **shared baseline**, not the differentiator. [^1] [^2] |
| 37 | +- ## One-line positioning (reminder) |
| 38 | + - **fnox**: one committed **`fnox.toml`** can orchestrate **remote refs**, **encrypt-to-git**, and **plain defaults**, plus optional **shell activation on `cd`**. [^1] |
| 39 | + - **[[secretspec]]**: one committed **`secretspec.toml`** is the **policy and inventory**; **values and migrations** live in **providers**, with a **Rust SDK** for typed in-app access. [^2] |
| 40 | +- ## Related in this graph |
| 41 | + - [[fnox]] — hub note for the tool |
| 42 | + - [[secretspec]] — existing stub and links |
| 43 | + - [[devenv/Blog/25/07/Announcing SecretSpec]] — motivation and critique of “encrypted secrets in repo” approaches from the devenv perspective |
| 44 | + - [[Person/Jeff Dickey/GitHub/fnox]] — canonical repo link |
| 45 | +- ## Footnotes |
| 46 | + - [^1]: https://fnox.jdx.dev/ |
| 47 | + - [^2]: https://secretspec.dev/ |
0 commit comments