141–150 of 170 posts
Earlier quoted context omitted.
"dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines." Would be nice if OpenWRT would stop including it by default
What else is out there that fits openWRT's use case? BIND seems like it would be a bit "heavy"
Earlier quoted context omitted.
The Bluetooth spec is horrendous, and from what I read, the hardware is equally horrifying. Bluettoth is a wireless bus, not one class a device and an implementation would need to provide hooks to the other subsystems like wscons (keyboard and mouse), audio and network. OpenBSD does not have kernel modules, so it’s either in or not.
> The Bluetooth spec is horrendous The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account. Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a…
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
Earlier quoted context omitted.
I'd say it's true. They chose to not implement SMP until consumer CPUs surprised them by going multi thread. And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.
But Bluetooth is basically a giant blast of security vulnerabilities. On the consumer side, yes, it's a big subsystem to drop, but on the server side, it's a little bit different! I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.
Yes, but this is exactly the point. And running OpenBSD is not a problem, until you run into a brick wall like this.
If you don't need it (and things like it), then that's all fine. As with everything, the last 10% takes 99% of the work, and code, and therefore contains about 99% of the security problems.
IIRC they were also very late to being able to run virtual machines, and even USB.
If you simply don't implement the things you don't need for a use case (e.g. a webserver) then that scales down to the fact that the compressor controller chip in your (dumb) fridge is not remotely exploitable too.
Earlier quoted context omitted.
For caching recursive dns, unbound? I got the feeling that dnsmasq does more than just recursive dns though?
Unbound can do authoritative dns. It is a bit clunky so usually what you do is have NSD for the authoritative parts and unbound for the recursive parts. but unbound has local-zone: stub-zone: forward-zone: auth-zone: directives. I am not the most sophisticated dns admin but I am fairly sure that just unbound by itself can do almost any dns party trick you care to throw at it.
I don’t know whether they’re right, but https://www.openbsdhandbook.com/bind/ and https://www.openbsdhandbook.com/unbound/ disagree with that, saying you need the sublingual nsd for that.
Earlier quoted context omitted.
I'd say it's true. They chose to not implement SMP until consumer CPUs surprised them by going multi thread. And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.
And as a counter example here you have openbsd "we are going to install a bgp daemon on every single device, because you never know when you may need one" I am not complaining, I like the feeling that I could single handedly rebuild the internet using only what is found in an openbsd base install. But wow, considering the size there is a lot in there. They definitely punch above their weight.
And it's not like the BGP daemon is on by default. That'd be dumb. You could equally say that any Ubuntu system has equally many steps to turn on a BGP daemon, starting with `apt install frr`.
I sure hope openbsd's BGPd doesn't have any suid binaries. And if it doesn't, well that might just as well be a vacation photo instead of a binary for all the "code" it is.
I agree that they're punching above their weight, but I would also say that they are falling more and more behind. 25 years ago they were more at par in what use cases they can address, and its performance. But now it's almost retro computing.
And it's fine! If you really only need a bog standard webserver, or router/firewall, then that's the use case and it solves your problem. And solves the problem without baggage.
I wouldn't use it for storage, though, since running a non-checksumming filesystem nowadays is a bit of a joke. (let's not get into btrfs. I acknowledge its history, but checksumming is not backups, and backups address the historical btrfs problems while not addressing at all the checksumming)
no poc = hyped false marketing from openai, lying about it is lpe. same with claude bug 27y.
Earlier quoted context omitted.
The Bluetooth spec is horrendous, and from what I read, the hardware is equally horrifying. Bluettoth is a wireless bus, not one class a device and an implementation would need to provide hooks to the other subsystems like wscons (keyboard and mouse), audio and network. OpenBSD does not have kernel modules, so it’s either in or not.
> The Bluetooth spec is horrendous The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account. Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a…
It mostly a drivers tree that describe how to probe for hadrware. Like mainbus -> pci -> xhci -> usb -> uaudio -> audio.
Earlier quoted context omitted.
As another commenter said, number of bugs increases with lines of code changed.
And some code is absolutely unnecessary. Look at the yes command. GNU version is optimized to death for no reason at all[1]. OpenBSD's version is as simple as it gets[2]. [1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
[1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...
Earlier quoted context omitted.
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
Oh it’s possible and people do it in embedded all the time at great expense, but that safety isn’t assured by using a “safe” language, it comes from the requirements, documentation and verification process. OpenBSD’s kernel was developed with security in mind but not that level of safety.
Earlier quoted context omitted.
My hobby horse is the lack of a “modern” filesystem on obsd. Without journaling I really don’t agree with the oft repeated claims it makes a good “router”. Any networking gear I’ve used is treated as an appliance and I don’t want an unfortunate power outage causing data loss.
What's the use for a writable filesystem in network gear, that is detrimental if lost at power outage? Some sort of very important logging?