Your people will rebuild the ancient ruins; you will restore the age-old foundations; you will be called Repairer of the Breach, Restorer of the Streets of Dwelling.
Close the breach the day a flaw goes public
When a flaw in Linux or a package goes public, the vendor's fix can take days or weeks. Repairer closes the breach on your servers in the meantime: a small program on each one blocks the flaw's way in, only under rules you signed, and steps aside once the real fix is running.
The stopgaps are written and checked by a swarm of gnosh.ai sessions on gno.land — AI that plans and remembers in Gno, so a long security review never loses the thread or skips a check — each with money at stake, so lying costs them. Your servers act only on signatures your own rules name: yours, your test machine's, people you chose, or your own AI's, within limits you set.
New, and built in the open. Most of what's below is built and tested on test machines, but it isn't on gno.land yet, and no one's servers run it yet. What's built, and what's next.
Why it exists
In November 2026 a flaw in Linux's handling of new TCP connections (CVE-2026-98432) could be set off by connection requests carrying a rarely used header field. Debian shipped a fixed kernel about three weeks before Ubuntu did. A stopgap that drops packets carrying that field, which normal traffic never does, covered those three weeks on every machine, and could come off once the fixed kernel was running.
The same week showed three quieter ways servers stay open: fixes installed but never in effect, because nothing rebooted into the new kernel; updates that had silently stopped for weeks behind one broken package; and a release past its end of support, getting no fixes at all. Repairer watches for those too.
Three rules that hold under attack
- Your servers act only on signatures your rules name. You sign your rules once, and approvals when they need you, on your own hardware wallet. Each server checks every signature itself, so a hacked watcher, a lying swarm agent or a planted security notice can't speak for you.
- A stopgap can only take something away. It can drop packets, switch off a kernel module or a service, remove a program's setuid bit, or set a kernel setting from an approved list. It can never open a port, add a program, download anything or run code.
- A stopgap takes itself off if it hurts. It goes on one machine first, with its undo already armed. If your services stop answering, it comes off by itself, and the rest of your machines take it only after a clean trial.
How a stopgap reaches your servers
- A flaw goes public. Your watcher, a small program on a machine of yours, reads the security news (Ubuntu's and Debian's trackers, the list of flaws attackers are already using, the kernel's own announcements) and knows what each of your servers runs. That list never leaves your network.
- It hits you, and no fix is running yet. The fix may not be out, or may be installed but waiting on a reboot. A stopgap is written: by the gnosh.ai swarm on gno.land, or by your own gnosh at home.
- gnosh.ai sessions check it. Checkers drawn by a lottery nobody controls run it on fresh test machines of every affected system: does it block the trigger, do ssh, web and mail still work, does undo put everything back exactly? Each works through a plan it can't skip a step of, puts down a bond, seals its results, and all are opened at once. Honest results match; whoever is shown wrong loses its bond to whoever showed it.
- It meets the bar you set. For each group of your machines, your rules say who may approve: you, your own test machine, people you chose (say, any two of three), or your own AI for stopgaps that only block.
- One machine first. The program on that server checks your rules and its own safety limits, puts the stopgap on with its undo armed, and sends a test packet to see it blocks the trigger. If your services keep answering, the rest of the group follows. The machines that matter most, like a blockchain validator, wait for your yes.
- It comes off by itself once the vendor's fixed version is running.
Was I hit?
When a flaw was public before its fix ran, you can sign a check that every affected machine runs once, read-only: a package's files changed, programs still running after their file was deleted or replaced, new setuid files, ssh keys, services or cron jobs since a date, kernel modules no package owns, and log lines since a date. A result is a count and a list of paths, never a file's contents or a log line.
Three tracks on gno.security
- Repairer (this page): stopgaps within hours of a flaw going public.
- Verify (next): checking that a vendor's fix is what it says it is, and isn't itself a backdoor. The xz backdoor of 2024 was switched on by a file that was in the release download but not in the project's public code; the first check catches exactly that.
- Immune: code checked for holes before attackers find them, with its owner's consent.
What's built, and what's next
Built and tested on test machines:
- ✓ the agent, on Ubuntu 22.04, 24.04 and 26.04 and Debian 12 and 13;
- ✓ signed rules and approvals, and the watcher with its page;
- ✓ reboots into new kernels, with a fallback if one fails, and was-I-hit checks;
- ✓ the test rig, gnosh at home, and a light client that checks what gno.land says;
- ✓ the gnosh.ai swarm's realm (draws, bonds, panels, appeals), on a local test chain.
Next: Verify's first check; your AI approving more kinds of stopgaps, each watched for its own way of failing; config-line stopgaps, such as sshd's LoginGraceTime 0 against regreSSHion; approvals signed in Adena; checkers who skip the work caught by test machines with planted faults; OpenBSD, then Red Hat's family; the realm on gno.land.
Want to try it? Read the code and run it on a test machine first: github.com/gnosecurity/repairer.