Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust (github.com)
I built it because I just wanted to share a password. Not spin up infra. Not register for some "secure" web app. Not trust Slack threads. Just send a secret.
Secrets are encrypted client-side with AES-256-GCM. You get a `uuid:key` token to share. Once someone reads it, it's gone. If they don't read it in 10 minutes, it expires and deleted.
Everything is verifiable. Every release is signed, SLSA-attested, SBOM-included, and logged in the Rekor transparency log. Every line of code is public.
There's also a browser-based companion: https://app.stasher.dev — works in a sandboxed popup using the same encrypted model. Share from the terminal, pick up in the browser.
No data stored unencrypted. No metadata. No logs. No surveillance.
---
GitHub (CLI): https://github.com/stasher-dev/stasher-cli GitHub (App): https://github.com/stasher-dev/stasher-app API (Cloudflare Worker): https://github.com/stasher-dev/stasher-api CI/CD (Open): https://github.com/stasher-dev/stasher-ci NPM: https://www.npmjs.com/package/stasher-cli Website: https://stasher.dev Browser App: https://app.stasher.dev (runs in sandbox from https://dev.stasher)
Built with Cloudflare Workers, KV, and Durable Objects. All code open, auditable, and signed.
Try it:
```bash npx enstash "vault code is 1234#" npx destash "uuid:base64key"
thanks for reading
19 comments
[ 3.3 ms ] story [ 44.4 ms ] threadyou probably want to unset HISTFILE and then set +o history before sending these commands to bash
1. Code is largely if not entirely written by AI
2. Author is completely anonymous, using a dedicated GitHub and HN account for this specific project
Both of these are really bad for security-sensitive software.
And your flow is: I encrypt my password; I upload the encrypted password to your server.
And I share the password to the encrypted password as plain text.
Why do I have to upload the encrypted password to your server, and not just use signal disapearing messages, or telegram secure channel disappearing messages to share the encrypted password there.
And I can use any other side channel to share the second password, like whatsapp, or regular plain mail.
It feels to me that you made a two step process into a one step process but increased the risk by adding you in the middle.
Why would I offload my trust to you instead of doing the second step?
>Buzzwords
>Author's English (when not written by a LLM) sounds translated
Doesn't inspire confidence.
Use GPG, it's not difficult. For non-technical folks, use signal or disappearing messages. For slightly more secure comms with non-technical people, use a combination of rot13 / caesar / similar.
>Doesn't inspire confidence.
I too have confidence only in projects made by those who English good. It's the reason why I'm estranged from my Swahili-speaking parents.
https://github.com/pglombardo/PasswordPusher
East to deploy, and just works, nice set of sane features and defaults.
And you've got all this "supply chain security" window dressing except nobody knows who you are and there's no community. So we have lots of records verifying that the published artifacts were authentically built by... someone... somehow.
This is AI slop, with a careless, checklisty, notion of what makes software secure.
The marketing language and actual design of the tool are also incoherent ("no server" and "no trust" both contradict how this thing actually works).
This post should probably be not just criticized, but flagged and removed.