271–280 of 517 posts
This is false as a generality. A memory safe, managed language doesn't become unsafe just because you have a race condition in a program. Like, say, reading and writing several related shared variables without a mutex. Say that the language ensures that the reads and writes themselves of these word-sized variables are safe without any lock, and that memory operations and reclamation of memory are thread safe: there a…
Earlier quoted context omitted.
It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…
I have recently come to the conclusion that everything I ever thought was "contrived" is currently standard practice in some large presently existing organization.
It's not even always the case that corrupted data structures (or even pointers) in C code are exploitable. You need attacker control of data and where it goes in memory. It's far less often the case in Python or Go --- in fact, it's basically never the case. As evidence for that claim: the zero memory corruption RCEs in all of shipping Go code, of which there is a lot.
Can you violate memory safety in C# without unsafe{} blocks (or GCHandle/Marshal/etc.)? (No.)
Can you write thread-unsafe code in C# without using unsafe{} blocks etc.? (Yes, just make your integers race.)
Doesn't that contradict the claim that you can't have memory safety without thread safety?
Earlier quoted context omitted.
The post is a demonstration that a class of problems: causing Go to treat a integer field as a pointer and access the memory behind that pointer without using any of Go's documented "unsafe.Pointer" (or other documented as unsafe operations). We're talking about programming languages being memory safe (like fly.io does on it's security page [1]), not about other specific applications. It may be helpful to think of th…
The thread you're commenting has already discussed everything this comment says. If you've got concerns about our security page, I think you should first take them to the ISRG Prossimo project. https://www.memorysafety.org/docs/memory-safety/
(In a separate comment about "what do people claim about Go anyhow", I linked the memorysafety.org page, but I did not expect it to help in getting you to the understanding that we can evaluate programming languages as being memory safe or not, where something from the company where someone was a founder seemed more likely to get a person to reconsider the framing of what we're examining)
Every time this conversation comes up, I'm reminded of my team at Dropbox, where it was a rite of passage for new engineers to introduce a segfault in our Go server by not synchronizing writes to a data structure. Swift has (had?) the same issue and I had to write a program to illustrate that Swift is (was?) perfectly happy to segfault under shared access to data structures. Go has never been memory-safe (in the Rust…
Swift is in the process of fixing this, but it’s a slow and painful transition; there’s an awful lot of unsafe code in the wild that wasn’t unsafe until recently.
Swift is strating to look more like old java beans. (if you are old enough to remember this, most swift developers are too young). Doing some of the same mistakes.
Anways https://forums.swift.org/t/has-swifts-concurrency-model-gone... Common problems all devs face: https://www.massicotte.org/problematic-patterns
Anyways, they are trying to reinvent 'safe concurrency' while almost throwing the baby with the bathwater, and making swift even more complex and harder to get into.
There is ways to go. For simple apps, the new concurrency is easy to adopt. But for anything that is less than trivial, it becomes a lot of work, to the point that it might not make it worth it.
Earlier quoted context omitted.
That seems contrasted by Rob Pike's statement in 2012 in the linked presentation being one of the places where it's called "not purely memory safe". That would have been early, and Go is not called memory safe then. It seems like calling Go memory safe is a more recent thing rather than a historical thing.
Keep in mind that the 2012 presentations dates to 10 months after Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention. I'd argue the definition was already changing by this point. It's also possible that Go was already discovering their version of "Memory Safety" just wasn't safe enough. If you go back to the original 2009 announcement talk, "Memory Safety" is listed as an…
Earlier quoted context omitted.
Skill? Go? With the amount of mistakes piling up over the years comparable to PHP at this point? Really??
These guys have each forgotten 10x than you know about programming. https://swtch.com/~rsc/ https://en.wikipedia.org/wiki/Ken_Thompson https://en.wikipedia.org/wiki/Robert_Griesemer https://en.wikipedia.org/wiki/Rob_Pike
Earlier quoted context omitted.
> But: everybody understands that. Everybody does not understand that otherwise there would be zero of these issues in shipping code. This is the problem with the C++ crowd hoping to save their language. Maybe they'll finally figure out some --disallow-all-ub-and-be-memory-safe-and-thread-safe flag but at the moment it's still insanely trivial to make a mistake and return a reference to some value on the stack or any…
Again: if you want to make that claim about correctness bugs, that's fine, I get it. But if you're trying to claim that naive Go code has memory safety security bugs: no, that is simply not true.
Earlier quoted context omitted.
People love to bring those as counter examples, without actually knowing a single fact about them. Dart was a victim of internal politics between the Chrome team, Dart team, AdWords moving away from GWT wanting AngularDart (see Angular documentary), and the Web in general. Had Chrome team kept pushing DartVM, it might have been quite different story. Carbon, good example of failure to actually know what the team purp…
> Had Chrome team kept pushing DartVM, it might have been quite different story. Trouble with that line of thinking is that Google never pushed Go either. It didn't even bother to use it internally (outside from the occasional side project here and there). Google paid some salaries. I'll give you that. But it has paid salaries for a lot of different languages. That is not some kind of secret sauce. > It is officially…
It is officially "not ready to use", it isn't a strawman as people keep complaining about nothing.
Earlier quoted context omitted.
Already explained in another thread, learn the politics of Dart, and Carbon is still on the drawing board.
So failures are some deep valid reasons whereas success is developers don't know any better language.
Lets also not forget Rob Pike famous quote regarding simple minds, as target audience.
As for Go, Kubernetes made it unavoidable, it is like UNIX for C, Web for JavaScript, and so forth.