[Oberon] [EXT] Memory-unsafe languages discouraged by US Government

[Pablo Cayuela]

I read the news about this, and I was gladly surprised to see Delphi-Pascal
on the suggestions.
I've also read another point of view of the report here:
https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/

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?

Prof. Pablo Cayuela
Argentina


On Fri, 1 Mar 2024 at 02:18, Skulski, Wojciech <skulski at pas.rochester.edu>
wrote:

> 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.
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Skulski,
> Wojciech [skulski at pas.rochester.edu]
> Sent: Friday, March 1, 2024 12:00 AM
> To: ETH Oberon and related systems
> Subject: [EXT] [Oberon] Memory-unsafe languages discouraged by US
> Government
>
> 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.
>
> 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
>
> BACK TO THE BUILDING BLOCKS:  A PATH TOWARD SECURE AND MEASURABLE
> SOFTWARE, FEBRUARY 2024
>
> https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20240303/5b9f1b12/attachment.html>