
Ask HN: Can CloudBleed Like Bugs Happen in Go, Rust or Java? - pritambarhate
I am really curious, can CloudBleed like bugs happen memory safe&#x2F;garbage collected languages like Go, Rust or Java? Especially if the program doesn&#x27;t use any libraries which depend on the native code.<p>If not, then do you think that major infrastructure related projects written in C&#x2F;C++ will be ever replaced by their counterparts which are written in memory safe languages? Or do you think the opposite argument also holds true to a great degree, if not memory related bugs like CloudBleed, then other types of critical bugs will arise from programs written in memory safe languages? For example, Java has had its share of critical security issues from time to time.<p>If you follow security then I am really interested in hearing from you about some of the bugs which had an impact as serious as CloudBleed or HeartBleed in a program written in a memory safe language.
======
ksherlock
Heartbleed is possibly in go, rust, java... pretty much any usable language.
The bug wasn't in the language used it was in the human using it.

[http://www.tedunangst.com/flak/post/heartbleed-in-
rust](http://www.tedunangst.com/flak/post/heartbleed-in-rust)

~~~
oconnor663
I think that oversimplifies the ways that Rust (and Java and Go) are safer
than C and C++. Of course in any language, the code that handles a buffer can
accidentally send that buffer to someone it shouldn't. The problem with unsafe
code, though, is that mistakes _anywhere in your program_ can leak the
contents of _any_ buffer. Languages that make unsafe code rare are much less
exposed to that sort of chaos.

This was the case here. An unsafe parser leaked memory that had nothing to do
with what it was parsing.

Related: [https://tonyarcieri.com/would-rust-have-prevented-
heartbleed...](https://tonyarcieri.com/would-rust-have-prevented-heartbleed-
another-look)

