2 pointsby dannytatom9 hours ago2 comments
  • graypegg9 hours ago
    Source?

    I would not trust this as-is. I do not like the `curl | sh` install strategy generally, but especially with something like this it feels sketchy.

    > We couldn't read your secrets even if we wanted to.

    Yes you can, you got to run a shell script with root privs when the cli was installed. You might only store ciphertext in your DB but skimming the shell script, it's dumping a mystery binary off your digitalocean spaces bucket and giving it all-user execute privs. There is no way to verify that binary isn't skimming my key.

    • dannytatom8 hours ago
      totally valid.

      to be super candid, this isn’t open source because i don’t have the bandwidth to maintain/support another open source project. that may change as time goes on, though.

      i get it’s a trade off, though, and i respect anyone not wanting to use it because of that.

      • graypegg7 hours ago
        I mean, to be super candid back at you: if you don't have the bandwidth to maintain/support another open source project, I also doubt you have the bandwidth to maintain a custom-built key/token/password store entirely on your own, for free.

        Your pitch for storing "API keys, tokens, and credentials" puts you personally in a rather liable position if someone uses this exactly as described, and you've made a mistake in code no one else has seen that either gives YOU those credentials, or leaks them somewhere another party can see them. (Analytics, logs)

        For yourself, this is kick-ass and solves a real problem. But I might refrain from pitching it for use by others because there's basically only downside for you in that.

  • rmroutsong9 hours ago
    Easy to use and intuitive, thanks!