[graypegg]

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.

[dannytatom]

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.

[graypegg]

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.

[dannytatom]

to clarify, i meant i don’t have the bandwidth to run this as a business and an open source project. not either, but both.

that said, i thought more on it last night, and i’ve decided to open source it. just going to be explicit in the README that i wont be offering support for anyone wanting to self host atm, just wasn’t built to be easy to self-host (external service dependencies and etc).