News for hackers. Stuff that matters.

A comment on Memory Safety Is Merely Table Stakes. Parent comment

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.
[ Parent | on HN ]
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.

[ Parent | on HN ]
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.
[ Parent | on HN ]
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?
[ Parent | on HN ]
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
[ Parent | on HN ]
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.
[ Parent | on HN ]