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