Conspiracy: The NSA has compromised all those languages' runtimes to spy on whatever is being run and passed through them. After all, that Utah datacenter[0] isn't going to fill itself.
[0] https://en.wikipedia.org/wiki/Utah_Data_Center
Edit: comprised -> compromised
As for that Datacenter in Utah - it is a large Government project. The idea that the US Government is efficient with its resources or that its operatives are trying to maximize the use of their resources is not well supported by historical precedent. If the project is written off as yet another make-work job project for a reliably red state then I am sure we can all sleep well knowing that our tax dollars have been well spent.
1) do black hat shit and risk prison time for gains that are hard to realize
2) work in white hat security and get paid a ton of money
3) work for the government and make very little money, but get to do black hat shit with impunity
It's pretty easy to imagine that the people submitting applications to work for the NSA have no interest in protecting the US from big bad overseas hackers.
1. Enjoy shooting guns and driving fast.
2. Have an interest in protecting the US.
While this topic is about the NSA I feel this are relevant questions:
Why do we still have a FDA given they fail so regularly to catch food and drugs that harm people?
Why do we still have a FTC given they've fail so regularly to prevent monopolistic behavior from telecoms?
Why do we still have a FBI given they fail so regularly to prevent mass shootings and domestic terror attacks?
Why do we still have a NSA given they fail so regularly at sharing information allowing foreign entities penetrating our financial and tech sectors?
Surely you recognize at some point inefficiency must give way to the question, has this been done intentionally? Especially since that is supported historically.
The question at hand is: Is a recommendation to use memory-safe programming languages evidence that those languages are less safe than we previously thought?
There are two competing notions:
A. This being announced now is evidence that the NSA has recently succeeded in finding a way to subvert the security guarantees of rust.
B. This being announced now is evidence that the good actors (or actors who want to appear good) in the NSA have finally gotten through the red tape to do what is nominally their jobs.
Their track record is spotty at best, and has only gotten worse over time. So to the extent that they are recommending using memory safe languages, that's great...it's advice that would be corroborated by other institutions, researchers, and practitioners. But the moment they recommend a specific set of technologies to use, that should give you pause.
That being said, the report doesn't specifically recommend just those specific languages, and merely provides them as examples...so as long as I'm not in charge of securing an adversarial nation/state's infrastructure, I'm not gonna worry about the potential nefariousness of this recommendation.
and that's just a glimpse into how bad things really are
Almost everybody misunderstands NSA's defensive mandate. They aren't corporate America's QA department, they don't have a "let's find and report exploits" mission - their defensive mission applies to "national security systems" and other "defense industrial base" ones. Those are computers/networks running fairly specific tasks; they are generally not internet connected, and sitting in secure buildings with 24 hour security and surveillance, so securing them revolves around a lot of physical security and controlled access.
YOU don't have one of these systems, corporation XYZ doesn't have one, there is no requirement NSA disclose jack shit to anybody unless they want to. And in the ETERNALBLUE case one of their tools leaked so they helped head off a lot of problems by voluntarily telling Microsoft about it.
As for who is responsible for this - I thought all the people here are free market worshipers. If Silicon Valley tech companies, one of the richest class of private enterprises in the world, need what are effectively government subsidies to cover their bug ridden insecure products, well that sounds like multiple market failures to me.
From HN comment guidelines:
> Please don't use Hacker News for political or ideological battle. It tramples curiosity.
"These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®."
I don't think there's any conspiracy, but it is interesting they don't mention JS or Python.
[1]https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Its arrays carried their size and range with them so you could safely iterate over them and safely (well, you'd get a runtime error at least versus C's "I trust you" model) access their elements. You had tasks and rendezvous since Ada 83 which could be used to protect access to data across other tasks (this was improved later with protected types in Ada 95).
You could tightly control, in the language not at runtime, the memory layout of records which was useful for over-the-wire protocols. With C you couldn't guarantee a particular packing for a struct would be uniform across compilers, with Ada you could. This also helps reduce bugs because you can apply DRY properly, in C you have to implement marshaling and unmarshaling yourself, in Ada it was just a given.
It's a very underrated language, mostly discounted because, it turns out, people are more into fashion and style than substance. "Eww, it uses keywords like `begin` and `procedure`" seems to be the #1 reason for rejecting it anymore, rather than any serious analysis.
Already-safe code remains safe if you wrap it with unsafe.
The implications to a code reviewer don't change much from that, however.
If course no one wants to ship actually unsafe code, and it is very rare to do it in Rust or modern C++ programs. But it is depressingly common in C programs and mostly-old programs like Chromium, and in the C libraries that programs of all kinds still depend on.
> Even with a memory safe language, memory management is not entirely memory safe. [...] Memory safe languages can also use libraries written in non-memory safe languages and thus can contain unsafe memory functionality. Although these ways of including memory unsafe mechanisms subvert the inherent memory safety, they help to localize where memory problems could exist, allowing for extra scrutiny on those sections of code.
Which I suppose is a reasonable way to put it. It's been said elsewhere, but my read of this document is that this is not a _definitive_ list of languages you should use, but rather a list of languages that make it much more difficult for programmers to introduce memory-safety bugs.
Maybe they're using the other golden rule: All languages starting with a P are old, crusty and should be avoided.
Anyway, even without C extensions a malicious input might trigger a memory related vulnerability in the interpreter. A compiled program written in a memory safe language could suffer from a compiler bug. Did it happen to Go and Rust?
Really, in the long term, "unsafe" and FFI interfaces should be removed from C#, Java, and Rust. That's the only way to be sure. in fact, I'd be willing to bet that in the short to medium term, with this recommendation, government contractors will soon be required to submit code that does not use these facilities. If you can't do it in C#, use Rust, if you can't do it in Rust, use Java, but you probably will no longer be allowed to pull in that wiz-bang c++ library.
It’s essential to doing many things.
I think they may simply be the first ones that came to the writer's mind.
From wiki: > Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers
Dart has isolates, so I thought it was memory-safe. But searching for buffer overflow or dangling pointer on dart's github repo returns results, so I'm still left wondering.
For this reason, experts like Schneier [1] have long advocated that the NSA be broken up so that these two missions do not fall under the same agency.
[1] https://www.schneier.com/blog/archives/2014/02/breaking_up_t...
Responsibility (issue advisories) for unclassified, commercial, non-defense internet is a confusing mess split between Commerce (NIST, https://csrc.nist.gov/about), DHS (CISA, https://www.cisa.gov/cybersecurity), Energy (CESER, https://www.energy.gov/ceser/cybersecurity if it is related to energy infrastructure), etc.
Throw in other agencies like DISA (https://disa.mil/About/Our-Work) as appropriate.
NSA's defensive mission is about securing National Security Systems. These have a fairly specific definition, and are not running in the average business.
I think the only instance of this kind of thing for which there is evidence is the elliptic curve debacle?
But this is the NSA, some amount of suspicion is always healthy.
honi soit qui mal y pense, but I spontaneously had the same thought when I read that.
You can leave a whale sized implementation hole in the finest of Rust applications!
Now, I know what you're thinking: "Yeah, the definition of 'compromised' is what I meant when I said 'You mean "compromised"?'. Why do you have to be so pedantic?"
Perhaps you are correct. Maybe it's better to not correct people on the internet when what they were saying is technically incorrect, but otherwise understandable.