Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I confused your username with jeanp413
    by axus
  • By the looks of it, someone way more skilled than me!
    by Fran314
  • If you're confident that Linux machines aren't going anywhere, the pass utility is a nice option.
    by allknowingfrog
  • This project is screaming for a pronunciation guide.
    by philipallstar
  • 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?
    by bhuvanbk007
  • 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!

    by Fran314
  • 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?
    by pzacik
  • 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

    by Fran314
  • It reads to me as "sex man" but aside from that, looks useful!
    by lolpython
  • I have to assume that's intentional, lol
    by soiltype
  • When I was kid, I was playing Nintendo games with my cousin, and my very straight-laced Mormon mom kept calling for me to come upstairs for dinner. I kept replying, "Just a sec!" as we tried to finish the stage. After a few times through this loop, she yelled "NO MORE SECS!" It's been a running joke in my family ever since.
    by DamnInteresting
  • And in these neck of the woods man is a short for manual. Funny name.
    by srean
  • 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

    by Fran314
  • 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

    by bglusman
  • 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

    by Fran314