Skip to content

Show HN: A simple way to send secrets between teammates

30s.sh
2 pointsdannytatom5 comments
On HN

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.

Comments

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.

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.

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.

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).

Easy to use and intuitive, thanks!

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.