Hacker News new | ask | show | jobs
by smabie 1156 days ago
Though written in C for no apparent reason. It's ironic to me how security focused OpenBSD is while at the same time looking down on any other language besides C.
3 comments

> for no apparent reason

Here's the list of hardware platforms that OpenBSD supports:

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

Note that when they say support, they mean that it's fully supported and actually works well, including that OpenBSD is fully self-hosting on that platform (read: "oops, the compiler OOMs on 32-bit" is a no-go).

Now, here's the list of targets that rust supports:

https://doc.rust-lang.org/beta/rustc/platform-support.html

Notice that all the OpenBSD targets are tier 3, and it's a strict subset of OpenBSD's platoforms. Even if we ignore everything else - a questionable choice - rust is unsuitable for writing core parts of OpenBSD because it can't actually build for all the systems that OpenBSD supports.

The point GP was (probably) trying to make is that OpenBSD's vision of security is at odds with its insistence on C, a notoriously unsafe and insecure language. There's no reason that the replacement language has to be Rust; it could be Nim or Zig or C# or Java or Vala or OpenBSD Custom Memory-Safe Language.

What it takes for OpenBSD to choose to support whichever language it wants to is primarily a commitment to actually spend its resources to support said language. That the OpenBSD targets for Rust are tier 3 is a sign of its unwillingness to consider moving away from C: what it takes to move from tier 3 to tier 2 is a set of maintainers who have a commitment to be responsive to patches, and an automated CI solution.

(Also note that OpenBSD is the largest Unix "stuck" in tier 3 for Rust. Solaris/Illumos, FreeBSD, and NetBSD all manage to have tier 2 builders. Even Fuchsia and Redox have tier 2 support!)

I think sometimes people forget the openbsd project was not started with a text editor opening an empty file.
> OpenBSD's vision of security is at odds with its insistence on C,

Their idea of security honestly seems very narrowly scoped on fixing a particular set of issues.

Just because something is written in C doesn't automatically mean it's unsafe. It's 100% possible to write safe C code. It's just not "automatic".
Safe C code is like functional communism, we are yet to see a real example. It probably could exist though.
This is just incorrect. Perhaps it's that you don't notice the safe C software because it doesn't cause a problem.
I'm guessing there aren't many rustaceans in the ranks of the various Military organisations of the world, outside of those planting vulnerabilities ofc...
SQLite? That has an extensive test suite and has been extensively vetted/checked.
True, but there are quite a few CVEs (of varying severity) https://www.cvedetails.com/vulnerability-list/vendor_id-9237...

Another way to look at that is "SQlite has had these bugs in the past, and our standards are unlikely to be that high". It does deal with a quite complex problem domain, but is still a strong warning re. vulnerabilities in C.

I actually am waiting for the increase in CVE number of rust replacements. So we can compare.

As for now, less exposure means less CVE. So the numbers are biased.

As usually, time will tell.

We have the data now https://security.googleblog.com/2022/12/memory-safe-language...

1.5M lines of Rust in Android and not a single memory vulnerability found, including in their unsafe Rust code. They also observe that the number of memory vulnerabilities decreases almost exactly inline with the decreasing use of memory unsafe language in Android.

The Android Rust code is also showing to have less bugs in general than the C/++ code.

OpenBSD doesn't have a Rust compiler in their core system. Having a core utility written in a language that isn't buildable with tools in their core system is a non-starter.

Once they have their own Rust compiler, or are able to import a Rust compiler that supports OpenBSD to the point where bugs on that platform are release-blockers for that compiler, and which is suitably licensed, they should be able to start (re-)writing core tools in Rust.