Writing the code is just the first draft. I know that’s a slightly deflating thing to hear if you’ve just spent a week getting something to compile and run, but it’s true, and it’s especially true for anything that’s going to face a hostile network. What actually turns a runtime into something you’d trust with a public-facing service is everything that happens after that first draft: the review. ocifbsd went through more than twenty distinct rounds of adversarial review — twenty-two, to be exact — and every single one of them was given permission to be ruthless. The commit history keeps them all, a numbered parade of “review batch” fixes, and honestly the list reads like a compact education in how systems software really breaks.
The bugs that lurk in C
If there was a recurring villain across these rounds, it was memory. Several batches went hunting for one particularly subtle and dangerous pattern: reallocating a buffer straight back into the same pointer. It looks harmless — it looks like the obvious thing to write — but it leaks the old allocation if the realloc fails, and it can leave you clutching a dangling reference when it succeeds. A dedicated growth helper was introduced to do it correctly, and then the bad pattern was rooted out everywhere it had taken hold: the list builders, the registry client, the runtime core.
Other batches went after equally nasty company: a use-after-free in the log daemon’s ring buffer, a cross-thread use-after-free that surfaced while listing cluster nodes, and a ring buffer cheerfully calling munmap on memory that had actually been handed out by calloc — a mismatch that’s invisible right up until it isn’t. These are exactly the kind of failures that sail through every functional test with a smile and then crash your service at 3 a.m. under real load, which is the worst possible time to meet them. Better to meet them in review.
Security as a first-class citizen, not an afterthought
A container runtime handles untrusted input as a basic condition of its existence — images, registry data, API calls, all of it arriving from who-knows-where with who-knows-what intentions. So security review earned its own dedicated series of batches, and the list of what got closed is worth reading slowly. Command injection through popen in the certificate and metrics paths was eliminated. Path traversal in the orchestration and networking code was guarded against. Decompression was capped so that a hostile image couldn’t unfold into a decompression bomb and eat the host alive.
And it kept going. Token authentication was bound to the authenticating identity to slam a bypass shut. JWT handling was fixed to close an out-of-bounds read. Cluster peer identity was pinned rather than trusting a CA chain alone — because in a cluster, “who are you, really?” is a question you want a very firm answer to. Key files were created 0600 from the very first moment, never lying around readable even briefly. And untrusted strings headed into hand-built JSON were properly escaped, to shut down log and audit injection before it could start. None of these are glamorous. All of them are the difference between a toy and a tool.
Why twenty-two rounds, and not just one?
You might reasonably wonder why it takes twenty-two passes to review one codebase. Couldn’t a sufficiently careful person just… do it once, properly? And the answer is genuinely interesting: no, because real review converges, it doesn’t finish. Each round fixes a whole class of problem — and the act of fixing one class quietly makes the next class visible. Tidy up the memory management, and suddenly the concurrency bugs step out of the shadows they’d been hiding in. Lock down the obvious injection points, and the subtler identity bugs finally stand out against the cleaner background.
So twenty-two batches was never a sign the code was bad. It was the mechanism by which the code became good — each pass sharpening the lens for the next. And it’s worth saying plainly: every shiny feature in the rest of these posts is only trustworthy because this unglamorous, repetitive, deliberately adversarial work happened first, out of sight, before any of it went live. The fun stuff rests on the boring stuff. It always does.