Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The web platform code in Chromium uses a C++ garbage collector [1] which gets a lot of benefits of a memory safe language and integrates well with V8/JS. That fixed the vast majority of issues without having to rewrite any of the code in another language.

[1] https://chromium.googlesource.com/chromium/src/+/refs/heads/...

See also the recent posts from the V8 team, ex. https://v8.dev/blog/high-performance-cpp-gc



Oh, I totally disagree with you. I'm well aware of how Chromium's C++ code works, and I'm aware of oilpan, I don't think it's fair at all to say it solves memory safety issues.

Proof's in the pudding. ITW exploits are there.


While Rust has safer defaults, exploits are still possible depending on how well unsafe {} blocks are manually checked for correctness.


Yes, which means you can grep for vulnerabilities.


Logic errors in unsafe blocks usually aren't grepable.

Speaking from experience using managed languages, and almost safe systems languages, with unsafe blocks support.


Yes they are, you just grep for "unsafe". Speaking from a career in information security, vuln research, and as a rust engineer.


It requires a human to actually look at the contents of the unsafe block.

Most of the time those humans are even rarer than those that validate unit tests are properly written.

Also you cannot grep for unsafe in binary libraries.


> It requires a human to actually look at the contents of the unsafe block.

Yes, that's an incredible capability - that a human can actually look to find bugs, that's insane, that's huge.

> Most of the time those humans are even rarer than those that validate unit tests are properly written.

Maybe, maybe. Is it rarer than fuzzing with sanitizers though? Or rarer than serious sandboxing efforts? When unsafe has been used gratuitously in Rust libraries the community has pushed back, to a fault.

I don't know what it is you want to try to argue here though. My questions were really targeted to someone at Google who can speak more directly to what I've been seeing for years.


I am trying to argue that just by using a safer systems programming language, the security exploits don't go away.

Someone needs to take care that the remaining 30% are taken care of.

While the unsafe blocks are still responsible for the remaining 70% if no one bothers to actually validate them.

Actix Web is a very good example, how the community still has to learn how to deal with such issues, and how effective the security would have been, if its security wasn't validated by fellow humans.

Yes it is definitly better than C, C++ or Objective-C, just not zero effort to keep it safe.


> I am trying to argue that just by using a safer systems programming language, the security exploits don't go away.

No one's on the other side of that argument.

> Actix Web is a very good example

A very good example of a project using unsafe and the community rejecting that?

> just not zero effort to keep it safe.

No one said it was.


> A very good example of a project using unsafe and the community rejecting that?

Only because the code was public.


If your >95% of your codebase doesn't feature unsafe, your rare human with the review skills only has to look at the remaining 5%, maybe 10% in order to understand what the 5% are doing.


Yeah, we all know how every project has unit tests, follows TDD best practices, is part of a CI/CD pipeline and has exemplary documentation.

Unsafe blocks are better than not having them, provided there is such human.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: