[userbinator]

The solution is simplicity, not more complexity.

This bug was introduced by the latter.

If you seriously think a buffer for a password needs to be dynamically allocated, the "safest" and most "modern" shit won't help. It'll just contribute to the ongoing decline.

[insanitybit]

> the "safest" and most "modern" shit won't help

But it would

[ehutch79]

I'm pretty sure their point was that there are fundamental issues at play, and that switching languages does not make the problem go away.

Rust/whatever is not a magic bullet

[selfmodruntime]

This is complete nonsense. There aren‘t fundamental issues at play. The issue is time and time again memory safety and bounds checking. Avoiding that topic in favor of „fundamental issues“ is disingenuous at best.

Rust / Go / Modern Language X is not a magic bullet for every problem, but it sure seems to be a magic solution for this very problem which occurs incredibly often and is easily fixed by avoiding archaic languages for security critical stuff.

[pjmlp]

This kind of problem would be a non issue on PL/I, JOVIAL, NEWP, and several others that predate C for systems programming.

[selfmodruntime]

YES. I agree entirely.

[Shish2k]

It wouldn’t solve every problem, but it would solve this problem, and this problem happens to be a regularly reoccurring problem with serious consequences

[insanitybit]

I get their point, it's just ironic since modern languages very much do not suffer from "I think a password needs to be dynamically allocated".

It's also particularly silly since there are plenty of reasons why a dynamically allocated password could be quite nice.

So yeah, I get that their point is "bad devs will write unsafe code no matter what the language is", this is just a terrible case to try to make that argument.

[ilyt]

In many of those issues switching language does indeed make it go away, because compiler will yell at the user if they do something stupid.