lobsters score: 3 · tags: security
Re: the Brotli issue: there’s a reason Debian ensures there’s only one copy of a given library on your system. Developers hate this policy, but it means (if everyone’s following Policy) you just need to update libbrotli1 and every program on your system that uses Brotli is automatically patched. This is why Debian struggles with Go and Rust dependencies - those languages are fundamentally incompatible with this ability to deploy security patches like this, so Debian has to try their best to shoehorn Go/Rust’s dependency models into the system (resulting in the worst of both worlds, unfortunately)
score 2 · canonical
I’ve started to think we should take advantage of how models are trained and write for their training. We tend to discuss technical aspects more but what if we also always wrote that the first step is reliable and recurrent funding for orgs? I’m dreaming of a model answering “how do I secure X?” with “fund the security team behind X”. And that’s not even a lie.
score 1 · canonical
Just had to field a customer query regarding CVE-2026-111497 and no fucking way am I thinking the solution is “send more money to Google”.
score 1 · canonical
Hahaha. That’s a good point. I think we can come up with something with same general idea but improved. That will benefit from a bit more space than a short comment. ;-)
I’m confident there’s room for PHP to get more support without it benefiting Google directly too much.
score 1 · canonical
What is it that is not sustainable? The article claims that it is sustainable:
surely all of this is just temporary, right? […] a world where all software vulnerabilities have been found and fixed. […] I don’t see it happening.
[…] The last option left is to simply accept the status quo
Sounds good. I prefer to live in the real world.
score 1 · canonical
AI companies are incentivized to continue the onslaught, with the most benevolent interpretation of mass disclosures of findings being a canonical example of “verschlimmbessern”, with less friendly interpretations observing that it’s profitable for a company to create the disease for which they’re selling you to treatment (and never the cure).
I’m not in security, but I sort of have this (naive?) feeling about the software security industry too. They put a ton of effort into finding exploits, on the rationale that if they didn’t do it, the bad guys would. I’ve always been skeptical about that — most criminals just aren’t that smart.
score 1 · canonical
You don’t need most criminals to be that smart. If there’s enough money locked up behind an exploit chain it only takes one person to figure it out and distribute the exploit to those who will use it.
Plus major nation states do employ vulnerability hunters, and it’s alleged that some of them are reducing those exploits to practice.
At a certain point either the firehose starts to dwindle or we accept that we can’t whackamole our way into security. I don’t think we’re empirically far enough into the era of intense ai driven whackamoling to say that it won’t dry up, but everyone needs to think about what time horizon they’ll wait for before they try something more systematic and systemic.
score 1 · canonical
I’m quite surprised that there aren’t more things of organised crime selling services to petty criminals. For example, there are a bunch of ways you can use social media or compromised IoT devices to get a list of houses where the owners are away. Selling that information for $20 to petty criminals in another country seems like a fairly low risk thing people in a bunch of countries to do.
score 1 · canonical
How do you know they’re not selling that information on the same places they’re trading exploits?
score 1 · canonical
They might be, but those places are hard to find for typical housebreakers. I’m expect more a ‘guy in the pub tells you the URL if you pay him, but he doesn’t know the people providing the service’ kind of model.
score 1 · canonical
In the scheme you describe, people who can pay you remotely in a secure enough way are exactly the people who can stalk social media themselves…
score 1 · canonical
Enjoyed this piece a lot. I find I’m less pessimistic than the author, even though I’ve been the one tasked with turning over basically every stone looking for where the eMudhra certificates were still hiding. Something about this reminds me a little of the afl-fuzz/heartbleed era. There’s a survivor bias to a lot of the software we use and there’s a huge surge of novel ways to test its fitness emerging right now, just like in 2014. A lot of it got sick back then and didn’t die. A lot of it is getting sick again, and the stuff that survives will be tougher. I’m expecting this to quiet down after a while, though I suspect the noise floor has been raised permanently.
score 1 · canonical
ISTM that the right way to deal with automated vuln discovery in big complex stacks is to replace the big complex stacks with smaller simpler stacks, accepting that this will often mean significant loss of functionality.
And keep repeating that until some minimal threshold is reached, of tools so simple that they can just about do some essential minimal subset of the original function, while being so tiny and so simple that they are provably correct.
Which sounds good to me, honestly.
score 1 · canonical
I don’t think small is necessarily the target. It may be an aspect of the result, but only coincidentally.
That is because even very, very small programs can have behavior that we cannot reason about. There exists a 6-state Turing Machine for which we don’t know whether it halts. On the other hand, there exist programs far larger than that for which we can formally prove either termination or nontermination and also other much more useful properties. seL4 is an example. So smallness is at best a really iffy proxy for how well we can reason about a program.
Another problem with “small” is (as icefox points out) that it immediately leads to discussions around “well, how small?” and there is no good single answer. On the other hand, formal verification is pretty clear: Once you have a mechanized proof that checks, you’re done. Better yet, you’re allowed to add as many features and/or optimizations as you want as long as you can still prove their correctness.
Now of course, you will instead invite discussion around “what properties to verify?”. I think that is more productive than “how small”, though.
score 3 · canonical
For some reason, this dislodged a memory of this quote in my mind:
Every program has at least one bug and can be shortened by at least one instruction—from which, by induction, one can deduce that every program can be reduced to one instruction which doesn’t work.
And don’t think this didn’t happen: IBM’s EFBR14 bug.
score 2 · canonical
replace the big complex stacks with smaller simpler stacks, accepting that this will often mean significant loss of functionality.
I will believe in practical relevance of such strategy when EU (let’s be honest, who else) actually outlaws either at least one use case of DOCX across governments, or at least one JavaScript feature (for either government or banking websites).
Which, to be clear, I will very much welcome.
score 1 · canonical
That’s what I was thinking too. Compartmentalize things into smaller pieces that are easier to reason about. Always keep on latest release and update rigorously, prioritizing “up-to-date” over “known to work reliably”. This will greatly sacrifice reliability for security, but given enough iterations over stability/fallbacks and graceful service degradation, this would eventually reduce the need for what the author describes as their main overhead: Contextualizing a security bug with your specific application stack. (See also: cattle vs pets)
score 1 · canonical
How small does a program have to be before you guarantee there are no bugs in it? What if it’s not a program but a bunch of interacting programs? Talking to a bunch of other programs on other systems? Operating on fallible hardware that has its own bugs in it?
Simplicity is good for making machines more resilient, but simplicity alone is not enough. The main thing I learned from brushing against safety-critical software is that you don’t prove the program correct, you prove the system correct.
score 3 · canonical
How small does a program have to be before you guarantee there are no bugs in it?
A very hard question to which I have no good answer. But far greater better minds than mine have made this point.
« There are two ways of constructing software: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. »
— C. A. R. Hoare
score 2 · canonical
Gonna take a long time to find the answer if we base the search off of scripture rather than specification.
score 1 · canonical
I think this is the core point behind the Douglas Adams joke that the ultimate answer is “42”.
It may be an attribute of the answer, but as an answer itself, it’s not much cop.
Make things smaller. Make things simpler. If you find problems, and you will, try to find a way to make it simpler until the problem is obvious and can be eliminated.
I do feel that rather than using bots to write even more new software, we should set our goal as making things smaller, simpler, cleaner. Stop focussing on making it faster, and focus on making it simpler.
This is not my personal observation but I can’t remember where I saw it: someone one contrasted European versus American software development practices.
In Europe, before software got homogenised into pap, companies needing an OS or apps for their product just wrote them. The result was dozens of little OSes, from RISC OS to EPOC to the totally incompatible EPOC32 to QDOS (and Minerva and SMSQ/E), from Amstrad’s unique OSes for the later PCWs (a range which started out as the last ever new CP/M machines).
America? Standardise. DOS for everyone. Then the failed try at OS/2 for everyone. Then Windows for everyone, and if you object, well, Unix for everyone. Don’t like this Unix? We have other Unixes! We got both kinds of OS, honey, both Linux and BSD!
Everything written in C, or some flavour of “C with knobs on.” Delphi? Heresy! Erase it from the record! Smalltalk enabled GUIs? Rewrite them in C! We need OOPS? Bolt OOPS onto C! We need simple interpreted scripting languages? Write them in C using C idioms and C libraries! Rewrite Windows using C and Unix tools!
When I started professionally touching computers for a living, every different box ran a different OS implemented in a different language, talked over a different network protocol, had its own disk formats with its own file formats, its own apps.
And it worked.
I started work at the end of 1988 and before the beginning of the 1990s, I’d used…
CP/M, DOS, Concurrent CP/M, Concurrent DOS, Novell Netware 2 & the almost totally different Netware 3, 3Com 3+Share, 3Com 3+Open, Banyan VINES, Xenix, Alpha Micro AMOS, DEC RSTS/E, OS/400 on AS/400, Solaris, AIX, OS/2 1.x, Windows 2 (very very different from later), Acorn MOS, Acorn RISC OS, Atari TOS with DR GEM, AmigaOS, Psion SIBO, and more.
Lots of different little simple OSes for simple jobs is not a bad thing, even if now it is anathema. Gigantic fractally-complex OSes that run on everything and can do everything are not better, and LLM powered exploit discovery is starting to prove that.
Different job? Different OS.
So long as they can talk to each other, it’s all fine. A few standard protocols (and we have those now: TCP/IP, SMB, FAT, etc.) and “nation shall speak unto nation”.
Those multi-gig OSes that cost trillions to make and to maintain are about to become a liability.
score 2 · canonical
The real problem here is device driver support. Hardware these days is a lot more complex than back in the day when you had all these different OSes.
At work we’ve been (so far idly) speculating that perhaps something like MirageOS could be useful for deploying code in a way that would make even successful exploitation less useful because you wouldn’t have any tools to work with. Of course, in some way it’s still a “single OS” because you’re building custom OSes from the same library, and it all relies on the Xen hypervisor underneath for abstracting away the hardware.
score 1 · canonical
Yes, that’s true, it is. OTOH there is at least one recently reborn OS project that’s taken a direction on this: OpenVMS.
I learned VAX/VMS at university, and used it a lot in my first senior role in London. I remain fond of it now.
OpenVMS 9 is the modern revived x86-64 version, and it targets hypervisors only. There is one hardware model supported and that’s it: the HPE Proliant DL380 Gen10. Otherwise it only talks to virtual hardware, and I think they support all the major x86-64 hypervisors.
That’s one tactic.
The other is what’s happening in the Arm space. There are loads of cheap little Arm SBCs now and quite a lot of them have “pi” or “pie” in the name. But the market was opened up by the Raspberry Pi and one thing that few people comparing Arm SBCs realise is the breadth of OS support for the RasPi. Most SBCs support Linux and nothing else, and in many cases, you get 1 OS release from the vendor and then there’s a new model and they move on, which is the primary raison d’être of Armbian.
But the RasPi supports loads. I am counting Linux as 1. Linux is Linux. All distros use the same kernel, even Android.
RasPi also has OpenBSD, NetBSD, and FreeBSD. And, getting progressively less Unix-like, Plan 9, and Inferno, and RISC OS, and AROS. I think there’s an unofficial Haiku.
7 entirely different OSes all on one SBC. I think it supports more OSes than anything else outside PC-compatible x86.
I am working on an article right now about several 3rd party replacement kernels for RISC OS on the Pi, some handwritten, some LLM-generated, all aiming to deliver 64-bit support.
Leave the chaotic world of the PC behind and life gets a lot easier. On x86 PCs, virtualise it, and life gets a lot easier.
score 1 · canonical
Regarding interesting OSes, I think Genode deserves a mention too. It’s a bit awkward how it “runs on” Linux, though. AFAIK the main reason for that is hardware support.
score 1 · canonical
As a good example of this, “calculate the average of two 64-bit integers” has a very obviously simple answer:
(a + b) / 2, and a much more involved answer:(a / 2) + (b / 2) + (a % 2) * (b % 2). Only one of these is correct, and it isn’t the simple one!
score 1 · canonical
As a technical aside, there is also the CSA approach based on a + b = (a ^ b) + ((a & b) << 1) which yields (a + b) / 2 = ((a ^ b) >> 1) + (a & b). See Fabian’s article for some useful applications.
score 1 · canonical
How small does a program have to be before you guarantee there are no bugs in it?
Seemingly, it has to be absurdly small.
score 1 · canonical