[OT] NSA guidance on software security

[Sergey]

On Friday, 11 November 2022 at 08:34:39 UTC, Siarhei Siamashka 
wrote:
> On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:
>> D is not yet on the list, but who knows, it might make an 
>> appearance on some revised version, if someone at NSA is 
>> paying attention.
>
> I find it more surprising that Python is not on the list. But 
> they just provide a few examples of safe programming languages.

The document has references about MSLs. The quote from one of 
them:
*The workshop consensus was that the Rust programming language, 
despite its initial learning curve, is particularly well-suited 
for safe systems-level development, even where performance 
requirements are important. Where performance requirements are 
less stringent, languages with garbage collection (GC), such as 
Java, Python, or Go, may be easier/simpler to use. Toolchains can 
encourage wider adoption of MSLs for programs, and thus, funding 
should be driven to the development of tools for MSLs. High 
performance MSLs like Rust should be well funded and enhanced 
with more tooling (e.g., static analysis tools, C2RUST 
converters, compiler plug-ins that facilitate translation to 
Rust/WASM), to make its ecosystem more robust.*

> But even if they decide to provide a complete list of 
> recommended programming languages, in NSA's shoes I would avoid 
> recommending D yet. Because is not @safe by default and the 
> @system code in "-release" builds has no bounds checking (so 
> goodbye memory safety). Additionally, catching arithmetic 
> overflows is the next safety frontier NSA may be looking into 
> and D has nothing good to offer (the checkedint library is a 
> fig leaf and non-practical in reality).

I think it could satisfy the broad definition of MSL:
*Even with a memory safe language, memory management is not 
entirely memory safe. Most memory safe languages recognize that 
software sometimes needs to perform an unsafe memory management 
function to accomplish certain tasks. As a result, classes or 
functions are available that are recognized as non-memory safe 
and allow the programmer to perform a potentially unsafe memory 
management task. Some languages require anything memory unsafe to 
be explicitly annotated as such to make the programmer and any 
reviewers of the program aware that it is unsafe. 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.*