Comment by tptacek
5 hours ago
Again: I am not disputing that there are correctness issues that come from having Go's concurrency and memory model, just like there are in (the large majority of) other languages with similar models. But those issues are not security problems, and security is what we're talking about when we talk about memory safety.
I feel like you're coming from the sort of constrained view you're accusing others of.
Iny experience, the ultra security focused view isn't what most people think of when they hear memory safety. It's one aspect, but one among many. For instance debugability is much nicer when you can't break the object model and get a nice trace out of the system versus when you're trying to find memory corruption with gdb or something.
That said, even the ISRG definitions I've found don't list protection from exploits. It does include out of bounds memory accesses in what makes a memory unsafe language, which would discount Go. Yes, they explicitly list Go as a memory safe language, but there's a good chance that they simply don't know about this behavior.
As someone who used to freelance in exploit research, the go behavior doesn't seem insurmountable for finding an exploit on its own. Frankly it's all the other ecosystem stuff that makes it harder. The fact that go code has a habit of being deployed multiple times a day, you a lot of times don't have access to the binaries, there's generally no dynamic (on Linux) so you have no relatively stable code to find gadgets in, etc. (Although there are aspects of the language like the relative simplicity of the compiler that do help you in some of those regards).