Seconded. I've also had great luck with the same author's fnox secret manager, especially because you can tell it to fetch some secrets from the user's laptop's OS keychain, and some out of 1Password, and some out of AWS KMS, and some out of [probably your own favorite provider (https://fnox.jdx.dev/providers/overview)].
replyfnox is mostly a copy of secretspec (and it's good to have one!),
so you'll find the same kind of support in both. I wish instead we'd collaborate with Jeff, but oh well.
replyThe difference is that we're providing an interface for applications to build with, with 8 SDKs available so you can have first-class support for secrets whatever you're bulding. I do hope fnox copies that too!
You keep saying that but I disagree strongly. Having looked at both fnox and secretspec, there are some obvious similarities because they're both in the same space, interacting with many of the same tools, and there are only so many ways to declaratively state "set the FOO variable with the 'my_secret_key' value out of the Bar provider".
replyThose inherent similarities aside, I don't see it. They don't seem to have a lot in common as far as design or implementation or configuration.
That's what we are using as well in our small team. `mise` for our non-sensitive values/ environment variables and then `fnox` (from the same author) to encrypt and manage the secrets.
`mise` has a plugin for `fnox` that allows to automatically load the secrets in the context when running a mise task/command.
This way, our secrets are never exposed, even during local development.
Setting this up was effortless. Pretty happy about these tools.
reply