3 ms·

This doesn’t go into any detail, not even saying what counts as a “memory safe language.” Are there any practical implications? Will the government change anyth

This doesn’t go into any detail, not even saying what counts as a “memory safe language.” Are there any practical implications? Will the government change anything it does?

hiddencost 3y ago
These documents tend to be vague because details could be wrong. They're used by the next layer of bureaucracy to justify programs, and by the next layer to justify plans, and by the next layer to justify designs, and the next layer to justify implementations.
- shanxxi 3y ago
  [flagged]
steveklabnik 3y ago
So, this alludes to "The Case for Memory Safe Roadmaps", discussed on HN here https://news.ycombinator.com/item?id=38611175 https://news.ycombinator.com/item?id=38611175 This document also does not provide a concrete definition of "memory safe language," instead only providing examples of such, but there are two things that are interesting about it: first of all, it provides C and C++ as examples of "memory unsafe languages," explicitly. The second is more towards your "practical implications" question. It says this: > With this guidance, the authoring agencies urge senior executives at every software manufacturer to reduce customer risk by prioritizing design and development practices that implement MSLs. Additionally, the agencies urge software manufacturers to create and publish memory safe roadmaps that detail how they will eliminate memory safety vulnerabilities in their products. By publishing memory safe roadmaps, manufacturers will signal to customers that they are taking ownership of security outcomes, embracing radical transparency, and taking a top-down approach to developing secure products—key Secure by Design tenets. The National Defense Authorization Act for Fiscal Year 2024 had language inside of it that said: > SEC. 1713. POLICY AND GUIDANCE ON MEMORY-SAFE SOFT- WARE PROGRAMMING. > > (a) POLICY AND GUIDANCE.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall develop a Department of Defense wide policy and guidance in the form of a directive memorandum to implement the recommendations of the National Security Agency contained in the Software Memory Safety Cybersecurity Information Sheet published by the Agency in November, 2022, regarding memory-safe software programming languages and testing to identify memory-related vulnerabilities in software developed, acquired by, and used by the Department of Defense." This is referring to the above. However, the final bill text seems to be missing this, and I haven't tracked down yet how that happened. The sentiment seems to feel like this is something akin to a softer version of the Ada Mandate: that being implemented in a memory safe language is a competitive advantage if you want to sell to the DoD, because using memory unsafe languages will require documentation explaining how you're mitigating the issues they have. Time will tell if that actually comes to pass.
deleted 3y ago
[deleted]
hrldcpr 3y ago
This is just a press release, but they link to the actual report, which goes into more detail, such as specifically calling out C and C++ https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...
- Tommah 3y ago
  Yeah, I think they're trying to say "Stop writing in C and C++, blockheads!" but in a more diplomatic tone. Most of the common languages today are memory-safe. Really, which ones aren't? C and C++ are the big ones. I guess throw Pascal in there if you don't use pointers correctly. Assembly lets you make indirect accesses anywhere in your allocated memory. Perl lets you leak memory if you create circular structures and then lose references to them. But Java, JavaScript, Go, Python, Ruby, etc. don't let you trample all over memory the way C and C++ let you. You can corrupt memory if you really want to, e.g. in Python by using ctypes to cast integers to pointers, but it takes a lot of effort.

This doesn’t go into any detail, not even saying what counts as a “memory safe language.” Are there any practical implications? Will the government change anything it does?

hiddencost 3y ago

These documents tend to be vague because details could be wrong. They're used by the next layer of bureaucracy to justify programs, and by the next layer to justify plans, and by the next layer to justify designs, and the next layer to justify implementations.

shanxxi 3y ago
[flagged]

steveklabnik 3y ago

So, this alludes to "The Case for Memory Safe Roadmaps", discussed on HN here https://news.ycombinator.com/item?id=38611175 https://news.ycombinator.com/item?id=38611175 This document also does not provide a concrete definition of "memory safe language," instead only providing examples of such, but there are two things that are interesting about it: first of all, it provides C and C++ as examples of "memory unsafe languages," explicitly. The second is more towards your "practical implications" question. It says this: > With this guidance, the authoring agencies urge senior executives at every software manufacturer to reduce customer risk by prioritizing design and development practices that implement MSLs. Additionally, the agencies urge software manufacturers to create and publish memory safe roadmaps that detail how they will eliminate memory safety vulnerabilities in their products. By publishing memory safe roadmaps, manufacturers will signal to customers that they are taking ownership of security outcomes, embracing radical transparency, and taking a top-down approach to developing secure products—key Secure by Design tenets. The National Defense Authorization Act for Fiscal Year 2024 had language inside of it that said: > SEC. 1713. POLICY AND GUIDANCE ON MEMORY-SAFE SOFT- WARE PROGRAMMING. > > (a) POLICY AND GUIDANCE.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall develop a Department of Defense wide policy and guidance in the form of a directive memorandum to implement the recommendations of the National Security Agency contained in the Software Memory Safety Cybersecurity Information Sheet published by the Agency in November, 2022, regarding memory-safe software programming languages and testing to identify memory-related vulnerabilities in software developed, acquired by, and used by the Department of Defense." This is referring to the above. However, the final bill text seems to be missing this, and I haven't tracked down yet how that happened. The sentiment seems to feel like this is something akin to a softer version of the Ada Mandate: that being implemented in a memory safe language is a competitive advantage if you want to sell to the DoD, because using memory unsafe languages will require documentation explaining how you're mitigating the issues they have. Time will tell if that actually comes to pass.

deleted 3y ago

[deleted]

hrldcpr 3y ago

This is just a press release, but they link to the actual report, which goes into more detail, such as specifically calling out C and C++ https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...

Tommah 3y ago
Yeah, I think they're trying to say "Stop writing in C and C++, blockheads!" but in a more diplomatic tone. Most of the common languages today are memory-safe. Really, which ones aren't? C and C++ are the big ones. I guess throw Pascal in there if you don't use pointers correctly. Assembly lets you make indirect accesses anywhere in your allocated memory. Perl lets you leak memory if you create circular structures and then lose references to them. But Java, JavaScript, Go, Python, Ruby, etc. don't let you trample all over memory the way C and C++ let you. You can corrupt memory if you really want to, e.g. in Python by using ctypes to cast integers to pointers, but it takes a lot of effort.