I just switched to single thread and didn't try to fix the issue. Single thread is fast enough to me, it has throughput ~ 730 Mbits/s in a OpenBSD 7.8 vm on a 7th gen i7 linux kvm host.

https://github.com/infinet/rs-wgobfs/commit/c5e62796

> This isn't anecdotal or “vague opinion” CVEs are facts

No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].

Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.

Lies, damn lies and statistics.

[0] https://www.suse.com/c/linux-kernel-cve-increase-suse-explai...

> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced

You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.

I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.

Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.

On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.

US export restrictions? There are broad license exceptions since decades, so kernels like Linux are free distributable. Same would apply to OpenBSD.

You are correct; OpenBSD is secure by default. And it's not subjective at all.

The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)

Remote (exploitable) holes are the ones we all care about.

I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.

> The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.

Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.

Great firewall and VPN server. You can setup wireguard with just ifconfig.

Don't most people use something FreeBSD based for production use ? I was under the impression OpenBSD was more used for testing and security research.

For personal devices I'm not sure why anyone would run a BSD in the first place

While true it doesn't answer why OpenBSD is considered more secure by default than Linux. Despite its BSD roots, macOS has had its share of CVEs:

https://www.cvedetails.com/version-list/49/70318/1/Apple-Mac...

Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.

OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.

One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).

https://en.wikipedia.org/wiki/W%5EX

More recently of course pledge and unveil were also added.

Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.

For a list, see here:

https://www.openbsd.org/innovations.html

Many things were later picked up by Linux distributions, kernel patchsets, compilers, etc.

> when configured correctly.

These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.

The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.

You misunderstand the Qubes' approach to security. You isolate your workflows into separate VMs, so that security of a single VM doesn't matter. For example, my secrets are stored in a dedicated offline VM. All kernel bugs in it are just not exploitable. I open my online banking in a dedicated VM, in which nothing else is ever opened. Which attack vector do you think can be used against that?

https://isopenbsdsecu.re/

(This site is extremely good and has fairly recent coverage, point-by-point, of all OpenBSD's mitigations. An important subtext to take to this is that OpenBSD has a reputation for introducing mitigations that exploit developers make fun of. Some of them are great, some of them less so.)

They do not have a strict "no binary blob allowed" policy. Concerning VMs, they have a policy of minimal modifications: https://doc.qubes-os.org/en/latest/introduction/faq.html#wha...

The dom0 is based on Fedora and has the Fedora's policy for firmware blobs. See also: https://doc.qubes-os.org/en/latest/introduction/faq.html#wil...

How many upgrades have you done so far? And how many kernel fixes?

Long time ago I maintained a couple of obsd servers, and the cost in time of upgrades and the (occasional) security fixes was substantial.

I still maintain a couple of servers, but if it wasn't because Debian makes it easier by automating most of it, I don't think I could do it.

Yet I miss my time with obsd. I'm very interested in your experience.

Edit: it was 3.6-STABLE. Things have changed since then.

Maybe I'm misunderstanding the video, but it looks to me as if the situation is:

You are root inside a sandbox. As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox.

(Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enough about OpenBSD to answer that.)

The parents tone wasn't warranted, but bugs like this could be more serious if combined with privilege escalation bugs in the sandbox.

Ideally, sandboxes should be like Vegas - what happens in the sandbox stays in the sandbox.

(I'm just speaking hypothetically here, I'm not knowledgeable about OpenBSD or it's sandboxes)

>Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment

Can you help figure out where does it say unveil does not really work when root is involved?