Like, I bet Anthropic and OpenAI run on a combination of Windows, Mac and Linux. That likely means that most intelligence agencies worth their salt have thoroughly penetrated those companies at one time or the other. So the model weights that those companies spent billions of dollars training are likely in the hands of all sorts of people all over the world.
Similarly for most of our weapons manufacturers. Unless they've really gone to great lengths like air gaps and such - and maintained that - the technical details of most American weapons are likely in the hands of many intelligence agencies.
Same for the banking details of politicians, and the daily schedules of people in power, and the messages everybody in Washington D.C. are sending each other and on and on. All of this stuff exists on computer networks that run on windows / linux with thousands of vulnerabilities. A treasure trove for intelligence agencies.
Similarly for most corporations. All the money spent on R&D and the results of that research can just be hacked away and taken out over the network because we chose speed over security. The whole idea of "Investing in R&D" seems kinda silly in that world. You put the fruits of your expensive research on a computer on a network. That network could be hacked by any hacker who can find any one of the thousand vulnerabilities, including your business competitors and geopolitical rivals.
So I don't think it was really fine.
I'm also pretty hostile to AI, but do recognize that these machines seem to be very good at finding exploits.
I'm sure there've been some some projects out there working to pentest/find cracks in OpenBSD via LLMs/agents/whatever-the-right-term-would-be...
But it is true the attack surface is much lower in OpenBSD on purpose, so hopefully it is overall more secure. But I'd like to see the numbers.
I think the only OS that's truly survived the agents looking at it was sel4, but I could be wrong.
Then they need to check again now. The frontier models 6 months ago have been leapt over by the current frontier models.
I did a double take when hearing about ksmbd. Brings back memory of khttpd and Tux.
They should build a monokernel implementation of CIFS and be done with it.
OpenBSD components are widely used. OpenSSH is one example used by most of HN.
OpenBSDs libc is also used by Android as another example. Also widely used.
Not everything needs to be dominant to be successful. That's a pure USian way of thinking.
In fact, we are much better of with it existing. Think of it as a safeguard in case Linux gets overwhelmed or we need to migrate in a rush.
Then we can compare with actual data.
Yes, openbsd has not had a torrent of bugs found, but I would say that the vastly bigger reasons for that are: 1) orders of magnitude people care about burning tokens and money to find the bugs in an OS almost nobody uses, and 2) it's simply much smaller. Can't have Bluetooth bugs if you don't have a Bluetooth stack.
I've pointed LLMs at obsd stuff, and even the simplest code, e.g. cat & find, had bugs and buffer overflows.
So no. Nobody can write safe C. Not hobbyists, and not "those evil corporations".
Don't hold back...
I like openbsd in theory, but every time I've tried something practical prevents actual use.
It's old now, but here are some thoughts of mine from 2019: https://blog.habets.se/2019/10/OpenBSD-in-2019.html
Did you report these findings? Because I think those bugs are live Canada, with your girlfriend.
Yes, I reported some of them. Some got fixed, some got ignored. You can search my name on openbsd-tech
I found more, but the ratio of ignored to fixed is too high to bother.
Years ago I also fixed bugs in the MPLS implementation. Like bugs I found immediately upon using the feature.
The find bug was merged the next day from what I could tell.
Yup, they did merge both find bugs.
The ignored ones seem to be my reported doas bug (not security problem, but directly contradicts manage about a config keyword detail) and efiboot.
IIRC the latter bug was like... this can never have worked.
I just checked the GitHub mirror, and those two are still not picked up.
There's no fundamental reason why all the checks applied by say, a Rust compiler, couldn't be applied to a piece of C code. Or checks that go well beyond that.
Tools exist to produce extremely reliable code (or even proven-correct code) for a number of languages.
But chances are those tools aren't used to the extent they could be. Or differences in developer culture on different projects. Some PHP web developer will (on average) have different resources, priorities & work ethics than say, someone working on avionics software.
If AI, advanced tool, or a security researcher can find a bug in existing code, then (at least in theory) same bug could have been found before it hit a repository.
But no... push "release", fix issues afterwards when reported. Gotta have developer velocity, right?
Imho it's more a choice rather than "can't write safe code in X".
If you don't believe that: pick a random open source project, and go through some changelogs. Feature introduced in version X, reverted in version X+1 because it broke existing stuff. Feature removed because hadn't-been-working-for-years-anyway. Code added to do X, but no.. doesn't do X, just the scaffolding to do X in next version. Code worked fine & passed tests on system A, but found to be needing a byte-swap on other-endian platform B.
Etc, etc, etc. There's just so much code out there that was broken on day 1. And not rarely known to be so, but released anyway.
I've certainly thought about how to improve my C++ after internalizing Rust. Unfortunately I've come up with very little. For every implementation of a Rust safety, I've come up with a way to easily (accidentally) break it.
So in the language, while I'd love to see it, I'm not so sure.
Now, if we can just get "a sufficiently smart compiler", then that'd be great. But that's rarely how that works. (cf. https://wiki.c2.com/?SufficientlySmartCompiler)
I've not looked much at formally proven code, but for such code, sure. Note that there are plenty of examples of bugs in formally verified code, too. Partly this is because one formally verified the wrong thing.
Maybe AI can write prefect assembly directly. Then we can all stop arguing about languages.
But in any case, if you want to make the case against my "nobody can write safe C" (or C without UB), and the argument is that they can, if an AI verifies every line. Then yeah, sure. But 1) who was actually writing the code, then? And 2) to the extent that the human was involved in writing the C, they probably made things worse, not better.
Even for AI coding C, there just needs to be one missing thing in the LLM's context, and a buffer could overflow. But for whole classes of bugs (though not all), the difference between Rust-without-unsafe and formally verified doesn't matter. I.e. you don't need formally verified against memory safety if it compiles, and there was no `unsafe` use.
> Gotta have developer velocity, right?
Not having AI at least review the code delta before pushing a release I would say is misconduct, today. It's the equivalent of editing your Perl cgi-bin in an editor live on the production server. That's not "production".
> pick a random open source project,
This is what I mean by not being "production". I won't judge anyone live-yoloing their blog, or "it works for my use case, it's GPL, provided AS-IS don't bother me", which is perhaps most opensource. You don't care if it works? Fine.
But you do care if it works, and/or is safe, and you push releases without AI review: yer fired.
Yes, we have to get from here to there, and I'm not saying release freeze until the entire codebase backlog has been AI-fixed, but yes today you need to have AI review the release delta. Ideally pre-commit.
SVN is CVS done right, but since the model is inherently ineffective for open development, you can't simply fix it.
They appear to be doing some NIH with "got" (https://gameoftrees.org/) but it's so aggressively uninviting (see the FAQ) that I don't want to spend any time looking at it, if they don't want me.
Oh my sweet summer child. Corporations waste so much compute it’s insane. At a recent engagement I asked Claude to analyse and optimise our cloud spend. It took about a day to learn that we spend about $2.5M annually, and 95% of that is complete waste that happens because of some bad architecture decisions. Then I took the computationally expensive parts that remain and asked Claude to rewrite in rust from first principles and optimise and it made a version that runs 40x faster and uses many times less ram. I suspect our $2.5M annual cloud bill could be replaced with a Mac mini.
But the company hasn’t implemented my suggestions because it’s not my department and they told me to stop. They don’t care. I suspect most corporates are like this. A 10% performance drop is nothing to these people.
Ahahaha! I laughed so hard at this because at work I regularly say something like, "why do we have a 32GB VM assigned to this system which runs a microservice that would run just as fast and reliably if we used Raspberry Pi instead?"
The amount of waste in big enterprises is unreal! The reason why we use a 32GB instance is because that's the minimum we're allowed to order for the reliability category of the app!
Speed requires a lot of code in the kernel, where that code can run fast.
There are kernels that do not have a thousand privilege escalation exploits. These kernels are smaller and much easier to check for bugs. But those kernels are significantly slower.
For many use cases, slower is not a problem. But for the large corporations who fund a lot of Linux development and use Linux in large data centers, every 1% slower can literally be millions of dollars worth of additional servers that are required.
OpenBSD shows that you can have a Unix security model without a thousand privilege escalation exploits. But OpenBSD is like 10% slower. So corporations won't use it because it would cost millions of dollars more per year and some of their software requires access that OpenBSD does not grant precisely because that access leads to security exploits (i.e. io_uring, eBPF etc. etc.)
You could also use like seL4, but that's slow too
So that's why. It's a business tradeoff between cost of servers vs cost of getting hacked, and cost of servers wins.