frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

France's homegrown open source online office suite

https://github.com/suitenumerique
430•nar001•4h ago•204 comments

British drivers over 70 to face eye tests every three years

https://www.bbc.com/news/articles/c205nxy0p31o
134•bookofjoe•1h ago•113 comments

Start all of your commands with a comma (2009)

https://rhodesmill.org/brandon/2009/commands-with-comma/
438•theblazehen•2d ago•158 comments

Leisure Suit Larry's Al Lowe on model trains, funny deaths and Disney

https://spillhistorie.no/2026/02/06/interview-with-sierra-veteran-al-lowe/
26•thelok•1h ago•2 comments

Hoot: Scheme on WebAssembly

https://www.spritely.institute/hoot/
86•AlexeyBrin•5h ago•17 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
778•klaussilveira•19h ago•241 comments

Stories from 25 Years of Software Development

https://susam.net/twenty-five-years-of-computing.html
35•vinhnx•3h ago•4 comments

First Proof

https://arxiv.org/abs/2602.05192
38•samasblack•2h ago•24 comments

Software Factories and the Agentic Moment

https://factory.strongdm.ai/
20•mellosouls•2h ago•17 comments

Reinforcement Learning from Human Feedback

https://arxiv.org/abs/2504.12501
56•onurkanbkrc•4h ago•3 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
1027•xnx•1d ago•584 comments

Coding agents have replaced every framework I used

https://blog.alaindichiappari.dev/p/software-engineering-is-back
173•alainrk•4h ago•231 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
168•jesperordrup•10h ago•62 comments

A Fresh Look at IBM 3270 Information Display System

https://www.rs-online.com/designspark/a-fresh-look-at-ibm-3270-information-display-system
24•rbanffy•4d ago•5 comments

StrongDM's AI team build serious software without even looking at the code

https://simonwillison.net/2026/Feb/7/software-factory/
18•simonw•2h ago•15 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
103•videotopia•4d ago•27 comments

Vinklu Turns Forgotten Plot in Bucharest into Tiny Coffee Shop

https://design-milk.com/vinklu-turns-forgotten-plot-in-bucharest-into-tiny-coffee-shop/
5•surprisetalk•5d ago•0 comments

72M Points of Interest

https://tech.marksblogg.com/overture-places-pois.html
13•marklit•5d ago•0 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
265•isitcontent•20h ago•33 comments

Making geo joins faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
152•matheusalmeida•2d ago•42 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
277•dmpetrov•20h ago•147 comments

Ga68, a GNU Algol 68 Compiler

https://fosdem.org/2026/schedule/event/PEXRTN-ga68-intro/
35•matt_d•4d ago•10 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
546•todsacerdoti•1d ago•263 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
419•ostacke•1d ago•110 comments

What Is Ruliology?

https://writings.stephenwolfram.com/2026/01/what-is-ruliology/
65•helloplanets•4d ago•69 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
364•vecti•22h ago•164 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
338•eljojo•22h ago•207 comments

Show HN: Kappal – CLI to Run Docker Compose YML on Kubernetes for Local Dev

https://github.com/sandys/kappal
16•sandGorgon•2d ago•4 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
457•lstoll•1d ago•301 comments

Microsoft open-sources LiteBox, a security-focused library OS

https://github.com/microsoft/litebox
372•aktau•1d ago•195 comments
Open in hackernews

Show HN: Stasher – Burn-after-read secrets from the CLI, no server, no trust

https://github.com/stasher-dev/stasher-cli
72•stasher-dev•6mo ago
Stasher is a tiny CLI tool that lets you share encrypted secrets that burn after reading — no accounts, no logins, no servers to trust.

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

Comments

jijji•6mo ago
wouldnt that command line output be sent to .bash_history of the logged in user?

you probably want to unset HISTFILE and then set +o history before sending these commands to bash

stasher-dev•6mo 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.
scosman•6mo ago
I feel like I’d rather send “uuid:cipertext” so the cipertext never touches a server, but logically the security seems the same.
stasher-dev•6mo 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
masfuerte•6mo ago
I feel like I'm being very stupid. If the key never leaves my machine, how do I share a secret?
stasher-dev•6mo 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 randomly generated UUID

The encryption key is never sent to the server. It never leaves your machine.

You are then shown a single string:

uuid:base64key

The uuid points to the encrypted stash on the server

The base64key is the encryption key you just generated

Only the person who has both parts can decrypt the secret

How You Share the Secret

You send the full uuid:base64key token to your recipient — over any channel you like slack or whatever.

When they run:

npx destash "uuid:base64key" on the token

Stasher:

Fetches the encrypted stash using the uuid

Deletes it immediately (burn-after-read)

Decrypts it locally using the base64key

Shows the secret

The server never sees the key. Not during upload or during retrieval.

cess11•6mo ago
So the ten minute thing is a trust issue. How are salts handled?
stasher-dev•6mo 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 minutes, it refuses the request.

Proactive cleanup — Every stash’s Durable Object sets a scheduled alarm to self-destruct after 10 minutes. This removes the coordinating DO and ensures the encrypted blob in KV expires (via TTL).

So even if someone tries to cheat the system, or access after the 10-minute window, they’ll get an error — the stash is gone.

This is part of what makes it “burn-after-read, or expire-after-time”. No guessing, no timers in memory or cron job workers.

How are salts handled?

Stasher uses AES-256-GCM, which does not require a traditional salt like in password hashing (e.g. PBKDF2, bcrypt). Instead, it uses an IV (initialization vector).

With a fresh 96-bit IV is generated for every encryption

AES-GCM uses that IV as part of the encryption process, ensuring non-deterministic ciphertext. The IV is not secret, and is uploaded alongside the ciphertext and GCM tag

On decryption, the IV is used to reconstruct the exact same cipher context

So in short: No static salts and no reused IVs

Everything you need to decrypt is bundled with the encrypted stash, except the key, which stays with the user (as part of the uuid:base64key token)

natch•6mo ago
>no accounts, no logins, no servers to trust.

>The uuid points to the encrypted stash on the server

No servers… “on the server.” hmmm, I must be missing something.

JCBird1012•6mo ago
I'd recommend changing your tagline -

> Share secrets from your terminal. One-time only. No accounts. No backend. No BS.

A server sure sounds like a backend to me.

stasher-dev•6mo 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
oats•6mo ago
What does "burn-after-read" mean? Just that it can't be retrieved a second time?
stasher-dev•6mo ago
Exactly. Once it's read it's gone. If it's not read within 10 minutes... It's gone.
cmeacham98•6mo ago
I'm sorry, but I would never use this because of two major dealbreakers (and I would encourage others to exercise serious caution as well):

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.

stasher-dev•6mo 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 chain transparency from day one: signed releases, SLSA attestations, SBOMs, and Rekor logs. You don't need to trust me you can see the code for your self.

Ultimately, you're right — if you can't verify it, you shouldn't trust it.

That’s the whole point of the system: zero trust and verifiable cryptographic guarantees.

Appreciate the scrutiny

mbreese•6mo ago
Cryptography/security is a trust business. Without some kind of personal (or even project) history, I know nothing about you or the project. And if I can’t verify you, I can’t trust you. The rest doesn’t matter much to me.

But maybe that’s just me.

stasher-dev•6mo 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 would agree. Appreciate your point of view and taking time to give feedback.

i_am_proteus•6mo ago
Would you please elaborate on how "the releases are signed" helps establish trust in the context of your anonymous developer account?
stasher-dev•6mo 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 post deployment. for example part of the build is a dry-run on the worker build, this is stored as part of the build so you can see / confirm the exact code that was uploaded and this code is signed.

arp242•6mo ago
What people mean with "trust" here is whether they trust there are no subtle security issues. While I think "don't roll your crypto" has been somewhat overstated at times (someone has to write crypto), there is certainly some truth in that you need to be very careful writing this code and that mistakes are incredibly easy to make, even for competent developers.

If I were to release something like this then people can see that 1) this is a guy with >20 years of various contributions to open source and he seems like a basically competent guy we can trust (as much as you can ever trust a single person), but also that 2) he's not a crypto guy and there may very well be oversights. Maybe there are none, but you know...

If someone like, say, Filippo Valsorda would release someone like this, then people could see that 1) is basically the same as me, and 2) he's also a well known crypto guy with a good track record. This is not a guarantee there are no oversights, but I would certainly be surprised if there were major ones. I would certainly trust that more than anything I would write.

The whole signing stuff is kind of a red herring IMO. I mean, it's not bad to have I guess, but honestly I don't really care. If anything, focusing to strongly on "box ticking security" so early on seems like the wrong thing to focus on.

stasher-dev•6mo 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 Crypto API only.

I'll send Filippo a Postcard and see if he will review it :-P

ta8903•6mo ago
Is this a bit?
cmeacham98•6mo ago
A "focused identity" with no links to other identities is anonymous by definition.

More importantly, this project is not "zero trust" and calling it such is borderline deceptive.

I can verify the artifacts you're shipping contain the code in the repo (or I could just clone the repo myself), but I cannot automatically verify that your code is non-malicious and free of bugs. That is what I am trusting when using your software, and I have serious doubts about the "free of bugs" part for AI generated software.

loloquwowndueo•6mo ago
I’m right there with you in mistrusting AI generated code but - you also can’t automatically verify that human-written code is non-malicious and bug free.
cmeacham98•6mo ago
I also now see that you're using em dashes in your replies - are even the HN comments AI generated???
ramon156•6mo ago
Some colleagues use LLMs to translate their messages to English. Same can ve applied here
natch•6mo ago
Humans also use em dashes — like that. My browser for one automatically creates them on HN if you correctly type a space, two hyphens then another space. Maybe the dude just has good grammar.
wrs•6mo ago
Everyone please just stop with the em dash hysteria. You just tried to use one yourself — apparently you just don’t know how to type it.
FergusArgyll•6mo ago
We'll find out in an hour, but I bet openai trained em-dashes out of gpt-5 and that will confuse a lot of people. At least you'll be able to write the way you want to...
indigodaddy•6mo ago
I use emdashes like this-- see the difference
wrs•6mo ago
Yes I do — and that’s not an em dash, it’s two hyphens. You’re not using a manual typewriter, you have Unicode. You don’t make an exclamation point from an apostrophe and a period, do you?
baobun•6mo ago
The bigger tell is the self-contradictions. "No servers to trust" etc.
mbreese•6mo ago
I’d also add the language to the mix. I know you can write good code with TS/JS, but the dependency surface is just so large, I’m not comfortable with security code written in it yet (maybe at some point). Add that the repositories were created in the past week, so we can’t see the actual dev practice (was it all vibe coded? What bugs were there?).

I hadn’t considered your second point, but even the authors GH account has an AI picture. I have no idea who this person is or what online/HN reputation they have.

pastage•6mo ago
I wish it was easier to run code in browser that you could know did not make any network connections, thinking mostly of the client creating secrets here.
kbbgl87•6mo ago
whats preventing setting up a proxy (like mitmproxy, burpsuite interceptor) in the browser? pretty easy
Sayrus•6mo ago
That requires a dedicated instance of your browser as (AFAIK) most browsers don't support per-tab proxy configuration. If I understood correctly, parent wants tabs to work normally but offline tabs (like the secret generator) to be airgapped.
pastage•6mo ago
Yes. I was thinking of pages that work well as stand alone SPA. E.g. some paint, graph and edit things that exists, I would like to force it offline.

The problem here is that I need this client to make ONE network connection to the internet to be able to store something. That is a big subject I do not have the solution for.

pastage•6mo ago
Cumbersome but easy. I have no problem with it but I have a real problem teaching users about it.
i_am_proteus•6mo ago
Why use this instead of GPG?
stasher-dev•6mo 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 trying to replace GPG, just a different use case.
h43z•6mo ago
Do I understand this correctly that the server here is only needed to make sure the secret it's only read once?
stasher-dev•6mo 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
coldstartops•6mo ago
You built it because you wanted to share passwords:

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?

stasher-dev•6mo 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 for me. I wanted an easy, CLI-first way to share one-time secrets without worrying about accounts, apps, or trust. If Signal or GPG works better for you that’s totally cool.

Stasher exists to make casual, secure sharing simpler not to replace tools you already trust.

coldstartops•6mo ago
Yes, valid, congratulations on shipping!

It's just that the entry level for adopting a new tool (for other people) is:

Convince my recipient to use this system instead of "Why not just send the password as we usually do on our secret chat."

And then we spend 20 minutes talking about it and me advocating for their unknown and unaccountable creator.

precompute•6mo ago
>LLM generated

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

freedomben•6mo ago
> Use GPG, it's not difficult.

Heh, maybe not for you and me, but if you've never tried to coach a less-technical person through setting up GPG and then using to encrypt/decrypt, it's an eye-opening experience

elpocko•6mo ago
>>Author's English (when not written by a LLM) sounds translated

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

precompute•6mo ago
Low language fluency with a purported high social effect / professional pretense is a good indicator for fraud. ESLs often translate English from their native tongue (which carries over the structure of their native tongue) instead of speaking it "natively". The author is pretty abysmal, and this doesn't bode well for his technical ability.
indigodaddy•6mo ago
The best tool I've found for password dissemination (you can create with it too, or not) is Password Pusher

https://github.com/pglombardo/PasswordPusher

East to deploy, and just works, nice set of sane features and defaults.

Thatdudeyouknow•6mo ago
Trust me bro!
pxc•6mo ago
Don't pass secrets via CLI args. Not only do they end up in your shell history, but they can easily be grabbed just by inspecting the list of running processes.

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.

Disposal8433•6mo ago
The commit history and messages do not inspire confidence. Everything seems generated by AI. Both facts show that you don't seem to know what you are doing, which is not a good sign for a security tool.
scosman•6mo ago
Okay, for fun I took a stab at this problem removing the server (using public keys instead), and minimizing the dependencies: https://news.ycombinator.com/item?id=44846495
nikolay•5mo ago
Both the site and the GitHub org is down. WTF?!