hey there. at every job i’ve had, people paste secrets into Slack and delete them really fast. i wanted a quick, secure way to hand off a credential that wasn’t that, so I built 30s. it’s a CLI that generates a local keypair and uses envelope encryption so the server never sees plaintext. you send to a recipient’s email, they decrypt locally, and secrets expire automatically (default 30s, maximum 24h). free to use, 50 secrets/month. |
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.
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.
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.
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).