<div dir="ltr"><div>I read the news about this, and I was gladly surprised to see Delphi-Pascal on the suggestions.</div><div>I've also read another point of view of the report here:</div><div><a href="https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/" target="_blank">https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/</a></div><div><br></div><div>And I wonder, is Oberon in any of its versions, a memory-safe language? What mechanisms does it have or need to achieve that goal?<br></div><div><br></div><div>Prof. Pablo Cayuela</div><div>Argentina</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Mar 2024 at 02:18, Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu" target="_blank">skulski@pas.rochester.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The reason I posted this note, apart from the intense feeling of satisfaction, is that it may provide an avenue for funding. I do not know how many of you are thinking of the Oberon language and the OS as the forward looking tool. Chris of course. But in any case, a document like this can be a solid launching pad. That's one of the lessons I have learned in the USA. Consider the Gov't roadmaps a funding opportunity. The rest is in the execution of this general idea. If you are in the USA then think how to make it a business. If outside then talk to your own Gov't. Get money, get going, advance the NW legacy.<br>
________________________________________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.inf.ethz.ch</a>] on behalf of Skulski, Wojciech [<a href="mailto:skulski@pas.rochester.edu" target="_blank">skulski@pas.rochester.edu</a>]<br>
Sent: Friday, March 1, 2024 12:00 AM<br>
To: ETH Oberon and related systems<br>
Subject: [EXT] [Oberon] Memory-unsafe languages discouraged by US Government<br>
<br>
The US White House put out a document discouraging the use of memory-unsafe languages like C/C++ due to their inherent lack of security. Apparently memory mismanagement is the cause of ~70% of security vulnerabilities. The Gov't recommended a number of safer languages instead, like Rust, Delphi/Pascal, Python, or Javascript.<br>
<br>
Quoting from the text: The highest leverage method to reduce memory safety vulnerabilities is to secure one of the building blocks of cyberspace: the programming language. Using memory safe programming languages can eliminate most memory safety errors. While in some distinct situations, using a memory safe language may not be feasible – this report examines space systems as a unique edge case and identifies memory safe hardware and formal methods as complementary ways to achieve a similar outcome – in most cases, using a memory safe programming language is the most efficient way to substantially improve software security<br>
<br>
BACK TO THE BUILDING BLOCKS:  A PATH TOWARD SECURE AND MEASURABLE SOFTWARE, FEBRUARY 2024<br>
<a href="https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages" rel="noreferrer" target="_blank">https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages</a><br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>