There is also 'doas' from the OpenBSD project. It's a replacement for 'sudo' with fewer features and a smaller codebase, with the aim of a smaller attack surface.
Recently learned that it doesn't implement using a new pty, which makes it vulnerable to TIOCSTI and TIOCLINUX ioctl attacks. Which doesn't matter on OpenBSD, because OpenBSD does not have these features. But Linux does, so not ideal.
https://github.com/Duncaen/OpenDoas/issues/106
I’m on the team that is implementing sudo-rs, and we are definitely aware of doas and other similar utilities. Doas does definitely have its usages, especially with the ‘just let me run this as root’ use case in mind. That said, there is also something to say for the more extensive configurability of sudo, and doas does sometimes have an execution model that might be a little too simple. And having another alternative is never a bad thing in my mind.
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.
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:
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'm guessing there aren't many rustaceans in the ranks of the various Military organisations of the world, outside of those planting vulnerabilities ofc...
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.
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.
Recently learned that it doesn't implement using a new pty, which makes it vulnerable to TIOCSTI and TIOCLINUX ioctl attacks. Which doesn't matter on OpenBSD, because OpenBSD does not have these features. But Linux does, so not ideal. https://github.com/Duncaen/OpenDoas/issues/106