So is this like a encrypt tool where we pass an external key to encrypt and we can use other apps to decrypt since key is not embedded in the tool? Or am I understanding it wrong?
That is true, but it's not specifically what makes it unique. Most encryption tool (like https://github.com/FiloSottile/age which is what secs-man uses under the hood) do not usually bake in the encryption key, rather they expect you to generate it and provide it.
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!
Yes, that was intentional. Originally it was just called "secrets-manager", I decided to shorten it only because it was (not really) too long to type, and a friend of mine had the realization that you can abbreviate it to something that sounds funny!
So is this like a encrypt tool where we pass an external key to encrypt and we can use other apps to decrypt since key is not embedded in the tool? Or am I understanding it wrong?
That is true, but it's not specifically what makes it unique. Most encryption tool (like https://github.com/FiloSottile/age which is what secs-man uses under the hood) do not usually bake in the encryption key, rather they expect you to generate it and provide it.
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!
It reads to me as "sex man" but aside from that, looks useful!
As pointed out by the other user, yes it is intentional, I always like a silly name
Also, thank you for the comment! I use it on a weekly basis and it has integrated very nicely with my setup
The name is great, we should bring whimsy back to software
I have to assume that's intentional, lol
Yes, that was intentional. Originally it was just called "secrets-manager", I decided to shorten it only because it was (not really) too long to type, and a friend of mine had the realization that you can abbreviate it to something that sounds funny!