> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix.
The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
I imagine the top two reasons unsafe memory access happen is:
1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue
2) memory management is hard
Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? Drawing attention to an unsafe area can help though.
As you can see, I'm running around in circles. Just like every discussion about this does. Until an avid Rust user puts their money where their mouth is, we're all just playing Armchair Programmer.
There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids.
I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are all the same borrow rules, and I know I have a bunch of TODOs in the code to go fix things like extra clones. The IDEs, while good, are not on par with other languages yet.
Basically it's a lot of work. And I commend the individuals who've paved the way for me with the std library in Rust, but we still have so much more work to do until there is a full OS env like GNU.
> Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks?
string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.
I think the hesitation there is that everyone has gotten it beaten into your head that writing new crypto libraries is dangerous. It's probably safer to use a library that has tons of eyes on it, but at some point we should do it.
But maybe for openssl staying close to the original API is useful, then one could maybe put a C API on top and use it also outside Rust.
In all safe alternatives to C, just like Rust sure you need unsafe at the Assembly FFI level and hardware integration like IO ports and interrupt handling.
But everything else can be just plain safe code.
Probably less than you think. What I think the limit is is that there are functions in glibc that present inherently unsafe interfaces. I'm not sure how many but it might be enough that writing libc in Rust is not that helpful.
But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections.
Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.
(Incidentally, there are other classes of vulnerabilities that Rust and/or its libraries heavily mitigate, such as deserialization issues along the lines of the Rails YAML bug.)
With all of that said however, I agree with you that it would be foolish to think that a rewrite would not be open to lots of potential vulnerabilities. At the moment might be prudent to continue to use and support the current libraries, but to also support efforts like rust-crypto in order to prepare for the future.
None of these things (except maybe some of the concurrency stuff) are quite new to Rust. It's just that C is such an old language that stuff that other languages have been doing well for decades were not available to systems software.
> Part of what makes Rust awesome is it forces correct...architecture.
That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before. There's plenty of insecure Java code out there.
And if you use "it won't be perfectly secure under X mitigation strategy" as an excuse to avoid doing X, your software will also be less secure.
> if you believe the language will keep you safe
safer != safe.
I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
I used to do systems programming back when the only OS written in C was UNIX.
C wasn't the first systems programming language.
Burroughs B5500 was written in Algol 68 with zero lines of Assembly. Just one example from many others in the pioneering days of computing.
There are other approaches to writing OSes.
If UNIX community ever wants to divorce from C there is a way, but there needs to exist a will as well.