Biden administration calls for developers to embrace memory-safe programing languages and move away from those that cause buffer overflows and other memory access vulnerabilities.
White House urges developers to dump C and C++::Biden administration calls for developers to embrace memory-safe programing languages and move away from those that cause buffer overflows and other memory access vulnerabilities.
They’re definitely not seen as an authority in this field. Why would anyone care what recommendation they make?
It's possible that they are acting on the advice of advisors who are authorities in this field.
And so why make one at all?
I expect it's because information and industrial security are components of national security, which is of great concern to them, and those things depend on software.
I'm not surprised to see this, given that state-sponsored electronic attacks are on the rise these days.
This is exactly why people sound sophomoric when they say "lobbying needs to go!" There are some drastic problems with lobbying as it is allowed now, but the last thing we need is the government regulating things they know nothing about without the input of experts. On top of that, it's nonsense that I can't pass my local councilman on the street and stop and push them to spend more time addressing important issues like climate change.
There have been words around this, like how software should be safe by design, but the regulation should come from the governing entity.
This is simply materialized now, but there has been momentum.
Embedded systems developer here. If you're programming on ARM or one of the other big microcontrollers there aren't many well supported options. ARM's official Keil compiler and libraries are C and C++ and I see no official movement to change that.
They have literally decades in building those tools.
Microsoft's multithreaded OS ThreadX is C code. They just bought it for a large undisclosed amount in 2018. It ain't going anywhere soon.
AWS's FreeRTOS is C. Not going anywhere.
Embedded development toolchains are very slow to change.
A large chunk of not most of robotic development is C and C++. Since working with a mixture of hardware, software, and even performance software here comes C and C++.
I think we should politicize code. It seems so unfettered by politics so far while so many other things are nicely split amongst party lines. Seems like maybe the Republicans should embrace C and the democrats can have python or something.
C isn't bad. It has been a good portable assembly language for ages, and remains so today. What's problematic is continuing to use it where more advanced languages now make more sense.
I won't defend C++, though. I'm happy to kick it to the curb now that better alternatives are gaining traction.
The problem with C++ is not the lack of safety features. It's the ever lasting backwards compatibility that is keeping it both alive and down at the same time.
Having to support 50 year old code, is going to limit any restriction you place. But it is usually the restrictions that make a language good.
Example: You can write perfectly good modern C++ code without any pointers. But pointers are so ingrained into the language, that it is impossible to remove them.
Rust is the main one for the kind of code that's typically written in C++. Most memory-safe languages make big compromises on performance, but Rust code tends to run about as fast as comparable C++ code.
“We, as a nation, have the ability—and the responsibility—to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem but that means we need to tackle the hard problem of moving to memory safe programming languages,” National Cyber Director Harry Coker said in the White House news release.
C is not the problem, it's sloppy "programmers" who cannot handle direct memory control and who do not understand the underlying system architecture and how a microprocessor operates. People who are good at writing C can make code just as safe as the safest Rust code.
While this is technically correct, it's tantamount to saying "just don't make mistakes", or arguing that a seatbelt is unnecessary because many are good enough drivers to not need it.
Languages like C and C++ do not prohibit the kinds of mistakes that the NSA told us two years ago lead to software vulnerabilities.
Other languages, like Rust, have higher guardrails built in and make it much more difficult to accidentally create the same failure modes.
While one disciplined programmer can in theory write correct code, once there is a small group of even good C programmers and a code base with more than around 3000-5000 LOC, there will be bugs. There is a good reason for tools like Valgrind etc.
While I think C and C++ are the problem, I don't think Rust is the solution, tho.
It is just too easy to shoot yourself in the foot when using a foot gun...
Sure the experts can avoid it, but that doesn't mean the foot gun is a good tool in general.
Your take is objectively false. This issue has been studied and the conclusion every time is that real programmers make memory-related mistakes all the time. Even if there are a few superhuman programmers who never get tired, have a bad day, or misunderstand an API, firing the 99.99% of programmers who aren't superheroes isn't a realistic solution to anything.
If you're an expert tightrope walker, you're likely not gonna fall off. You can just do it without too much issue. When you're doing it over a chasm, and you don't plan on dying, you'd still probably prefer a harness though, wouldn't you?
Edit:
I'm not saying C is a bad language or anything, but for important applications the safety of actually memory safe languages is vital for lower-skilled programmers and still a good assistance for higher-skilled programmers, as we're all humans and it doesn't hurt to try and avoid the mistakes we will eventually make.
I'll say it. C is a bad language. There was a time when it needed needed to exist and using it was a smart choice, but it has outlived its usefulness for anything but legacy code and niche use cases like FFI. It's in essentially the same category as Cobol.