Hacker News new | ask | show | jobs
by zefix 1237 days ago
Honestly #4 applies as much as ever. - At least in most regards.

The thing is: The 'security researchers' which I've had contact with focus mostly on hacking and memory corruption attacks.

The thing is: This is a solved problem by now!

And yet, instead of teaching students to avoid the horrible tools, which cause those problems, they keep on teaching how to penetrate and fix.

It's maddening.

1 comments

Please tell me you have already thrown Firefox, Chrome, old Microsoft Edge and whatever browser out of window and are posting to HN with you rewritten-in-Rust lynx.

Not being able to rewrite the world or convincing people to stop using memory unsafe languages is entirely unrelated to what security researchers do.

I'd love to stop having to build complicated lifetime model in my mind to figure out whether there are hidden code paths for a UAF, but at the same time this is the best thing I can do to secure what we have today, now it's on you to rewrite the world.

No.

We need to stop compromising.

Yes, there is a lot of old code.

No, I can't do it all on my own.

But we can do it as a profession. Refuse to take jobs, nag managers, refuse to by hardware that only supports C, etc.

If construction was as ridiculous our fiels, we'd still use asbestos.

> Refuse to take jobs

Well, I'm unfortunately not in a place where doing so makes sense. Unless you mean only auditing Rust code.

> nag managers

I already do so. This doesn't change much. There are still too many must-be-evolved C++ projects (no easy incremental rewrite path forward), it is impractical to have engs put significant effort into rewriting in Rust. It's really difficult to convince someone to fix something ain't broken.

People coding in C++ are just as desperate as you, that's why someone bring up Carbon [1], a half-baked experimental project to the world last year, instead of just using Rust. Sure, they would like to use a memory safe language as possible. No, they still have to get their job done.

> refuse to by hardware that only supports C

If it supports C, we can make it support Rust, it's a very fun weekend project to bring-up some nostd Rust code on it.

[1] https://github.com/carbon-language/carbon-lang