Memory safety is necessary, not sufficient

Memory safety is necessary, not sufficient
steveklabnik.com

Regarding your last sentence: I don't think Steve Klabnik has a newsletter and the blog post does not annoy anyone with a call to action in any shape or form.

The government buys technology from wherever, and until recently they never really cared where they got it from. If they need a USB Emulator, they buy the same Chinese Gotek from Ebay that you or I buy, and they get the same "Driver CD" full of buggy, broken English software, written by one person for $27 over the course of about 7 hours. Same thing with DVR systems, access controls, network appliances, access points. I've worked on government projects that were using 20 year old, broken, encryption libraries on active web servers. And when brought to their attention the people who use it don't care, and the people who are capable of doing something about it will never find out because it's too much work to replace and nobody wants to take that Zoom call.

I think the author is getting a little over-excited about Rust. Granted, they are a Rust developer. I'd love it if we could build everything in my favorite language. But the government doesn't want to replace everything with Rust. The government wants results. Period. It is the DOD, NSA, and CISA who need to become experts on how to realize those results. And they will probably release guidance that says "if you can't program securely in a memory unsafe language, don't use a memory unsafe language". The thing I think the author is missing is that nobody is going to mistaken "Made with RUST!" for "Impossible to cause undefined behavior!"

You can be a terrible programmer and still create undefined behavior, insecure code, data leaks, or any number of other problems in a memory safe language.

What the government is going to do is implement strict code import controls, similar to the export controls we already have. Purchasing departments will have to get software purchases signed off multiple times by qualified parties, and department leaders will have to prove that the technology they procure is adequately safe. In some situations I anticipate that means re-writing a bunch of code in Rust, and in other situations I'm sure that means hardening existing C. The majority of the government's security holes that need to be patched are coming from low quality unvetted imported technology, low quality self-written code, and code that should have been replaced 20 years ago. While it's exciting to think that this could mean a renaissance for the author's technology of choice, I just don't see it working out that way. If the government could write memory safe code, it would have. Rust isn't safe ENOUGH to save the government from itself alone.

Like my Gotek USB emulator reference. The device costs $50, and it's pretty much the ONLY option you have for emulating a floppy drive with a USB stick in a bunch of obsolete hardware. The software that it comes with was written by a Chinese high school student in C++ during a study break and it is about as insecure and sketchy as you would expect it to be.

If you're the government looking to buy this, your choices are;

1. Buy this sketchy retroft device that is insecure and may be backdoored for a cost of $60.

2. Replace whatever needs the retrofit for a cost of $2m.

3. Write your own drivers for $100k.

Currently they just use the $60 device. The upcoming policy changes will take that option off the table for a lot of agencies, forcing them to make wiser purchasing decisions. It doesn't automatically mean Rust wins the day, or that rust deserves to win the day. It means intelligent conversations must be had and difficult decisions have to be made that used to get avoided.