However it doesn't fit quite the same niche that my tool does. If I understand it correctly (though I only read those two links) fnox is more about how to use the secrets, ie given an encrypted description of the secrets, how to make them accessible to programs (kind of like sops?)

With my tool, secrets on the device are in plaintex and simply accessed by path reference by the respective programs. The focus of secs-man is more on exporting, ensuring integrity, and importing (possibly to remote machines). All of this, while being manually recoverable even without the tool.

Still, interesting project! Might take inspiration from it for some features

Also, thank you for the comment! I use it on a weekly basis and it has integrated very nicely with my setup

This is true for secs-man too: when you export it prompts with "Enter passphrase:" and you enter the passphrase (I am considering extending it to read the passphrase from a file or from an environment variable, or piped in from stdin, but I'm still not sure what to think of if from a security standing point and I they don't fit my current use so I don't have it in the current TODO)

What makes it unique is that it can be completely emulated by hand (even though it might be a bit tedious) from just a terminal with bash and age installed. This is explained a bit better in the blog post or in the "philosophy section" of the README, but the main point is that (in my opinion) you should NEVER find yourself vendor-locked-in for any data, in particular for secrets. However, you will always need tools for managing them. My tool is designed to be usable and avoid vendor-lock-in, meaning that even if you lose access to the tool you are not locked out of your tools!

I have probably phrased it better in the linked blog post, I invite you to read it if you're still curious. I'm here for any other question!