News for hackers. Stuff that matters.
Re:Memory Safety Is Merely Table Stakes by tptacek on Thursday June 26, 2025 @05:11PM (#44391425)
I think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python).

We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

Re:Memory Safety Is Merely Table Stakes by olarm on Thursday June 26, 2025 @05:58PM (#44391896)
> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.

Re:Memory Safety Is Merely Table Stakes by npalli on Thursday June 26, 2025 @07:50PM (#44392593)
> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.

Re:Memory Safety Is Merely Table Stakes by tptacek on Thursday June 26, 2025 @09:04PM (#44392950)
People keep coming up with all these examples of things still written in C/C++. Sure. So are most AAA games. But so far nothing that's been identified --- maybe excepting databases, but vulnerabilities there are still rare --- that is a meaningful component of insecurity, which is what "memory safety" addresses.
Re:Memory Safety Is Merely Table Stakes by spacechild1 on Thursday June 26, 2025 @11:21PM (#44393428)
> that is a meaningful component of insecurity, which is what "memory safety" addresses.

There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.

Re:Memory Safety Is Merely Table Stakes by tptacek on Friday June 27, 2025 @12:58AM (#44393810)
It would be better for everyone if everything on a forwardgoing basis was written in a memory-safe language.
Re:Memory Safety Is Merely Table Stakes by spacechild1 on Friday June 27, 2025 @01:37AM (#44393963)
What difference does it make for a video editor or DAW?
Re:Memory Safety Is Merely Table Stakes by adgjlsfhk1 on Friday June 27, 2025 @02:41AM (#44394257)
iphones have already CVEs from memory safety issued in image formats. is entirely plausible that a similar issue could exist in video or audio codecs
Re:Memory Safety Is Merely Table Stakes by wolf550e on Friday June 27, 2025 @03:27PM (#44399538)
The parser is attack surface, but that's the only part of something like Photoshop that has to be secure. The actual editing features can be insecure.
Re:Memory Safety Is Merely Table Stakes by zahlman on Thursday June 26, 2025 @06:22PM (#44392064)
To be fair, there's a pretty clear difference between achieving memory safety with a garbage collector and run-time type information, versus achieving it through static analysis.
Re:Memory Safety Is Merely Table Stakes by fiddlerwoaroof on Thursday June 26, 2025 @09:11PM (#44392981)
Static analysis is worse and limits the programs you can write in annoying ways?
Re:Memory Safety Is Merely Table Stakes by zahlman on Friday June 27, 2025 @02:51AM (#44394311)
I like dynamic typing, but the point wasn't about holy warring. The point is simply that it's different.
Re:Memory Safety Is Merely Table Stakes by tuveson on Thursday June 26, 2025 @06:24PM (#44392084)
> browsers and operating systems

And the VMs for the two languages that you mentioned above (edit: though to be fair to your comment, I suppose those were initially written 20+ years ago).

Re:Memory Safety Is Merely Table Stakes by chubot on Thursday June 26, 2025 @06:29PM (#44392116)
There’s also google, yandex, baidu, and bing, which are incredible amounts of c++ code

And probably lots of robotics, defense, and other industries

Granted, those aren’t consumer problems, but I would push back on the “last redoubts”.

We should absolutely move toward memory safe languages, but I also think there are still things to be tried and learned

Re:Memory Safety Is Merely Table Stakes by Ar-Curunir on Thursday June 26, 2025 @05:42PM (#44391759)
and cryptographic code.
Re:Memory Safety Is Merely Table Stakes by wglb on Thursday June 26, 2025 @10:20PM (#44393216)
My favorite crypto bug was not a memory safety issue: https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squ...

Was a fascinating detective story to illustrate it.