The White House (yes, that one) wants to hear your thoughts on open-source and memory-safe programming languages

Links
#1

Press Release:

The actual Request for Information:

Includes choice quotes like (emphasis mine):

The federal government recognizes the immense benefits of open-source software, which enables software development at an incredible pace and fosters significant innovation and collaboration. In light of these factors, as well as the status of open-source software as a free public good, it may be appropriate to make open-source software a national public priority to help ensure the security, sustainability, and health of the open-source software ecosystem.

…

Potential Areas of Focus

  • Area: Secure Open-Source Software Foundations
    • Sub-area: Fostering the adoption of memory safe programming languages
      • Supporting rewrites of critical open-source software components in memory safe languages
      • Addressing software, hardware, and database interdependencies when refactoring open-source software to memory safe languages
      • Developing tools to automate and accelerate the refactoring of open-source software components to memory safe languages, including code verification techniques.

I wonder if anyone here is an expert in memory-safe programming languages or open-source software and would be interested in helping the US govt decide where to throw its money to promote these topics? :thinking:

11 Likes
#2

I am not by any means an expert, but it is an incredibly pertinent subject to several fields of interest of mine, and I was just writing about it as background for a community proposal that I am working on. I’ll summarize the relevant portion:

Cryptography is [even harder] for functional programming languages. Properly implementing techniques such as sanitizing memory, performing operations in constant time, are already difficult enough in languages such as C, and in a lazy functional language it is made even more difficult by such things as the potential for references to be kept alive within thunks. As a result, the space of [functional cryptography] is relatively under-explored and under-developed, having favored other languages where such things are easier to manage.

However, if we accept this downside as a part of a trade-off, and explore the ways that functional programming is beneficial to [cryptography] (monads, type systems, referential transparency), there is then also the potential for [functional cryptography] to be made easier. The functional machinery of Haskell is well-suited for adding important contextual control to [cryptography], and can help prevent or eliminate many issues and errors in ways that languages such as C cannot.

I am specifically speaking about memory safety as it applies to cryptography, but it is broadly applicable when you include responsibilities like data integrity, error correction, and verifiability, under which memory safety may be included.

I think Haskell has the potential to produce significant high-quality tooling for such things if we have funding and focus - while laziness certainly presents some challenges, Haskell excels at using the type system to make things like buffer overflows impossible. I think that the whole space [of functional memory safety] is under-explored.

2 Likes
#3

Austral maybe? Not sure what the status is, but it’s something other than Rust.

#4

Considering the growing number of hardware-related memory exploits e.g. “ZenBleed”, a better place for all those resources would be to improve the rigour of “specifying silicon architectures” :

Timely Computation (2023) - Conal Elliott.

…at least then we would be “building on stone”, proverbially (and somewhat literally).

4 Likes
Handling errors correctly
#5

I keep a list :expressionless:

adds ZenBleed to the list

1 Like