Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Secs-man, a secrets manager you can (not) rely on

github.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Show HN: Secs-man, a secrets manager you can (not) rely on

#11

Post by rirze »

Fran314 wrote: post #9
bhuvanbk007 wrote: post #8

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…

Sincerely, I don't get the motivation for this. It feels like `age` is pulling most of the work I care about. `age` is the only tool here encrypting and decrypting secrets, are you managing the orchestration of secrets with your tool?

Re: Show HN: Secs-man, a secrets manager you can (not) rely on

#12

Post by Fran314 »

rirze wrote: post #11
Fran314 wrote: post #9

Earlier quoted context omitted.

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…

Sincerely, I don't get the motivation for this. It feels like `age` is pulling most of the work I care about. `age` is the only tool here encrypting and decrypting secrets, are you managing the orchestration of secrets with your tool?

age is pulling all the encryption work. What the tool does is the import/export managing.

First of all, it creates snapshots for each export and it ensures to pull the latest snapshot during import. Also, it manages the hashes of the secrets (created on first export) and of the export, which ensure that the files are not corrupted, so that when I import I can be sure that no bitrot happened and the secrets that get copied on my machine are bit-identical to the ones I exported.

That being said, it's true that this is not a lot of work to be pulling. As I wrote in the blog post, this Rust tool could have been a Bash script. However I opted for not-bash because I don't feel particularly comfortable with bash and I like to have types. If I knew Go, it would have been a solid option

Re: Show HN: Secs-man, a secrets manager you can (not) rely on

#16

Post by bglusman »

This is an interesting motivation for the project... I kind of get it, but, have you looked at fnox[0][1]? Curious how you'd compare/contrast goals with that if so, I think I prefer that as its not coupled to a single encryption tool (age) but supports age as well as multiple cloud or local options behind one unified interface... I think it can even mix multiple stores together? but I may be missing something/didn't read thoroughly yet...maybe there's a reason fnox doesn't work as well with Nix? fnox was discussed here previously[2]

[0]https://github.com/jdx/mise/discussions/6779 [1]https://github.com/jdx/fnox [2]https://news.ycombinator.com/item?id=45722931

Re: Show HN: Secs-man, a secrets manager you can (not) rely on

#18

Post by Fran314 »

bglusman wrote: post #16

This is an interesting motivation for the project... I kind of get it, but, have you looked at fnox[0][1]? Curious how you'd compare/contrast goals with that if so, I think I prefer that as its not coupled to a single encryption tool (age) but supports age as well as multiple cloud or local options behind one unified interface... I think it can even mix multiple stores together? but I may be missing something/didn't…

I didn't know about it existence, it looks like a nice project! Also, it would probably play nicely with Nix (by writing wrappers instead of symlinks)

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

Re: Show HN: Secs-man, a secrets manager you can (not) rely on

#20

Post by Fran314 »

pzacik wrote: post #19

What advantages does this have compared to something like the .kdbx format invented by KeePass, which is open and implemented by many other open-source tools than KeePass itself?

Depends on your usecase. If I understand it correctly, KeePass is "just" a password manager, not meant to deploy files to a system.

So for example if you wanted to backup and later import/deploy your ssh key, you'd have to manually take the saved value from KeePass and paste it into a file in the correct location (I'm only assuming tho, I don't use KeePass)

My tool is intended more for deploying files to a system where they can be used by various programs. This is closer to something like sops/sops-nix.

I guess that my wording "secrets" might be ambiguous on this. It's not meant to be a password manager or work as one. It's meant to be a tool for backing up and deploying SSH keys, wireguard keys, and so on

Post reply on HN