stasher-dev

9 ms·

1. 1.▲
   by stasher-dev 1y ago

   Nice one! I was the author of the original post and got roasted. Lol Even if no one uses my project as a result of this guys work. I am pleased it's generated a safer outcome for everyone and from a more trustworthy source.
2. 2.▲
   by stasher-dev 1y ago

   Your skepticism is valid and if your flow already includes: A secure messaging tool (e.g. Signal), a GPG workflow or local encryption or a team that uses shared password vaults. Then to be fair Stasher might not be better. I built Stasher f
3. 3.▲
   by stasher-dev 1y ago

   Thanks for your feedback 'I tried to use of the shelf stuff for the crypto and utilised what I believe to be battle tested. CLI uses node.js built-in crypto module only -randomBytes - createDecipheriv - createCipheriv. Web app uses Web
4. 4.▲
   by stasher-dev 1y ago

   Yes, that's a fair comment technically speaking: Cloudflare Workers + KV + Durable Objects is a backend. I was trying to imply No user accounts, no persistent database, no stateful sessions etc I will reword - thanks for the feedback
5. 5.▲
   by stasher-dev 1y ago

   Yes, you are understanding it correctly, the server (Cloudflare Worker + Durable Object + KV) in Stasher is only needed to enforce the burn-after-read behaviour
6. 6.▲
   by stasher-dev 1y ago

   zero setup, burn after read, no key exchange required, GPG is ideal for persistent trust relationships (e.g., signing emails), Stasher is purpose-built for temporary relationships. To me GPG is overkill for sharing simple shares. Defo not t
7. 7.▲
   by stasher-dev 1y ago

   It means the releases are cryptographically signed using GitHub OIDC, with SLSA v1 provenance and entries in the Rekor transparency log. That means:You can verify every artifact against its source code i.e I have not tampered with the code
8. 8.▲
   by stasher-dev 1y ago

   So the ten minute thing is a trust issue? Stasher enforces expiry in two layers: Reactive expiry — When someone tries to retrieve a stash (destash), the Durable Object checks the creation timestamp before serving. If it's older than 10
9. 9.▲
   by stasher-dev 1y ago

   I get it. An 'anonymous' author is a deal breaker for some. I respect that. The repo is public. The releases are signed. The attestations are published. Nothing hidden. If that’s not enough — totally fair and I am sure many others
10. 10.▲
    by stasher-dev 1y ago

    When you run: npx enstash "my secret" Stasher performs everything locally: Generates a random 256-bit encryption key Encrypts your secret using AES-256-GCM Sends only: the ciphertext the IV (initialization vector) the auth tag a r
11. 11.▲
    by stasher-dev 1y ago

    Thanks for raising these concerns — totally fair in the context of security tools. I’m not anonymous, just cautious. I’m a solo builder, and this is a focused identity for the project. In fact, that's why I implemented full supply chai
12. 12.▲
    by stasher-dev 1y ago

    Exactly. Once it's read it's gone. If it's not read within 10 minutes... It's gone.
13. 13.▲
    by stasher-dev 1y ago

    Hey. Only the ciphertext is stored on the server; the key never leaves your machine. The uuid:key format is just a pointer to the encrypted payload. Without the key, the server’s stash is useless. Zero-knowledge by design
14. 14.▲
    by stasher-dev 1y ago

    Great point — I’m planning to add a --stdin option explicitly for cases like this. Thanks for raising it. I will add to the readme in the meanwhile.
15. 15.▲
    Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust(github.com)

    72 points by stasher-dev 1y ago|55 comments