CISA is stupid. Logic bugs don't go away with Rust.
Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
31–40 of 100 posts
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#32There's go to be billions of loc of critical C/C++ software left. By 2026? Doesn't sound realistic.
The title is wrong. The guidance only says they should have roadmaps by 2026 unless the end of support date is before 2030, then they can tell customers to get bent and deal with C/C++ until support runs out. Roadmaps are easy to produce, so compliance will be easy. Follow through will be more interesting to see. And, again, the guidance is that they should have roadmaps. They aren't mandating anything.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#33“The development of new product lines for use in service of critical infrastructure or [national critical functions] NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.” Now that's a strong statement.…
I wonder if this is a real solution. "Memory safety" has sure been pushed hard the last few years, but this feels more like a "we need to do something, this is something, we should do this" kind of response than anything that will really address the issue.
If security-through-virtualization had been the fad lately, would that have been proposed instead?
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#34that means you have to use rust for system level programming then? there is really no other alternative at system programming as far as memory safe is concerned, that uses no GC or VM.
You can have a systems programming language with garbage collection. Most concerns regarding GC are around unpredictable pauses, but you can absolutely design a predictable GC suitable for real-time applications.
Rust is not the only option. The Ada programming language was developed in the early 1980s, primarily for the U.S. Department of Defense (DoD). Ada was designed for safety-critical embedded systems and real-time applications, especially in areas like avionics and military systems. In 1991 the DoD mandated Ada, but then reversed the decision in 1997. As I read the linked article and the governments "strong stance" I'm wondering if history will repeat itself.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#35So... F35?
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#36This misses the point. C/C++ are unsafe because that’s how implementations happen to work today.
C/C++ can be memory safe. Fil-C/C++ is a good example. It’s not a new language, just a different way of implementing it.
Here’s more info about Fil-C: https://github.com/pizlonator/llvm-project-deluge/blob/delug...
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#37Cool. Is this going to require phasing out systems written in C/C++ with horrible security track records like Linux and Windows? Or are they going to get a "too critical to be improved" exemption?
[deleted]
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#38> "Companies have until January 1, 2026, to create memory safety roadmaps."
This doesn't bode well for open source software not backed by a "company" that can write these roadmaps and deliver on them.
aka Sounds like Microsoft, Oracle, and other's lobbying has been effective.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#39Cool. Is this going to require phasing out systems written in C/C++ with horrible security track records like Linux and Windows? Or are they going to get a "too critical to be improved" exemption?
Do you have an OS written in a memory safe language with a good security track record we can switch to? If we start building now we might have a prototype by 2030.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#40“The development of new product lines for use in service of critical infrastructure or [national critical functions] NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.” Now that's a strong statement.…
I think it is important to recognize that this will only apply to generic normal software, which is already mostly written in memory-safe languages for government e.g. Java. Data infrastructure with state-of-the-art scale, performance, and workload requirements will continue to be written in C++ for the foreseeable future, largely because there is no alternative. Maybe Zig some day?
A pattern I’ve seen (and used myself) is that the heavy core engines are written in C++ for performance and maintainability but skinned with a Rust API wrapper. Rust is closer to a “better Java” than a C++ replacement for extreme systems software.