31–40 of 58 posts
Earlier quoted context omitted.
https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=u...
Sure. I haven’t looked at these exact blocks, but the point is that they were using tons of unsafe that they didn’t need to . Unsafe exists to be used, when it’s neccesary. 11 now? Iirc it was on the order of 100 before.
This article casually throws around definitions of 'memory safety' that are massively different. Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things. AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour…
Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't any.
Earlier quoted context omitted.
The blog post was published on 2018-08-18. Perhaps Debian stable was shipping some other version back then?
No, it doesn't seem like it to me: https://metadata.ftp-master.debian.org/changelogs/main/r/rus...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906585
..this means i386 and these sysadmins who apply only security updates were still affected at that time.
Some readers seem to be getting thrown by the casual tone of this article. For those struggling to not rage my two takeaways were: * Automated checking of rusts std lib could improve rusts security * Don't use unsafe if you don't need it * Releasing a fix for a security vulnerability should be complemented with a cve if you want people (such as anyone using Debian) to not still be vulnerable two years later Note: des…
> But dealing with those things is necessary to run code on modern hardware, so something has to deal with it.
The main point is that "unsafe" is the weakest link in the language, since it bypasses the safety guarantees of Rust. Therefore it needs solutions outside of the language (in the form of how bugs are handled, and programmer culture) to minimize the risks it brings.
> There is a highly effective technique for discovering vulnerabilities that I haven’t applied to Rust yet. It beats everything else by a long shot, and can be used only by the bad guys who want to break stuff, not the good guys who fix it. It’s… searching the bug tracker. > The proper way to handle them is to file [memory safety bugs] into a database called Common Vulnerabilities and Exposures (CVE for short) so tha…
By which I mean using bots, obviously.
Would it be an exaggeration to flag all memory issues as security issues by default?
This article casually throws around definitions of 'memory safety' that are massively different. Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things. AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour…
> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't…
> For example, Erlang — that funky language that people use to program systems with 99,9999999% uptime (no, that’s not an exaggeration) — has repeatedly shipped with a broken implementation of Map data structure in its standard library. …during the period ‘maps’ was a experimental/beta-feature.
Unless you have to type “Please enable maps even though it will break all of my code” every time you run it, that's a distinction most people will ignore. If something is useful enough to ship, people will want to use it — helping test it is even the point — and only the most prominent “This is terribly unsafe” warnings will be heeded.
I think people made their choice and the developers of the said maps are not responsible for whatever comes out of map’ lack of security.
Earlier quoted context omitted.
> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't…
...Are you really trying to use “gophers” as a derogatory term?
Earlier quoted context omitted.
Unless you have to type “Please enable maps even though it will break all of my code” every time you run it, that's a distinction most people will ignore. If something is useful enough to ship, people will want to use it — helping test it is even the point — and only the most prominent “This is terribly unsafe” warnings will be heeded.
So what’s more important, to be secure or to ship, then? I think people made their choice and the developers of the said maps are not responsible for whatever comes out of map’ lack of security.
Similarly, you could require some sort of opt-in / runtime warning approach where you have to explicitly opt-in to having them and they're clearly marked as unstable. If you had to compile with a `ENABLE_INSECURE_MAPS` or do some sort of import from an experimental module it'd make it a lot easier for someone to recognize that they're doing something less stable than normal, similar to Rust having you mark code as unsafe.
Earlier quoted context omitted.
> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't…
...Are you really trying to use “gophers” as a derogatory term?
It's hard to google a good example but here's one I found:
> A creative and passionate community of Go developers and users (“Gophers”) has grown up around the language, and today there are U.S. Go conferences, European Go conferences, […] even a group for LGBT Gophers (yes, “Gayphers”).
https://blog.newrelic.com/technology/golang-experts-follow-o...