Shnatsel

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db… Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it. This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve! I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.

>And the error(s) in arithmetic occurred outside any unsafe block. This is completely misleading. The unsound check for integer overflow[0] was in 'safe' code but just because the code is not in an unsafe block does not absolve you of any potential bugs, and the subsequent writes to memory that were in an unsafe block clearly did not care about prior mistakes that were made. The PR that introduced the vulnerability[1] was due from switching a safe method to one that uses unsafe for performance reasons, I suggest checking out the commits for both the introduction of this bug as well as the commit that fixed it as they're both short and the actual bug only occurs on one short line. It's also worth noting that the vulnerability could have been found using a fuzzer[2] that did not exist (for Rust) at the time but that does now exist, and that integer overflows are checked for on debug builds (but not for release builds by default, again due to performance reasons) but that in this particular vulnerability it would have been extremely unlikely that any legitimate code would have triggered this integer overflow. The take away here isn't that 'even 'safe' languages get it wrong', but that unsafe operations are difficult to do correctly, and that's true in either C or Rust. There's further discussion[3] on this bug if anybody is interested. [0] https://github.com/rust-lang/rust/pull/54397 [1] https://github.com/rust-lang/rust/pull/48657 [2]…

All modern OSes are written in C and/or C++, unsafe code is inevitable there. Some people tried to fix that a few times (hardware java machines, singularity/midori, etc.), wasn't good enough. > unsafe code called from Dictionary.Remove For creating, and checking for, empty reference. Rust standard library uses unsafe way more. That design has consequences, e.g. check this https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable… It's somewhat harder to screw up when you can rely on VM guarantees, and don't need that level of trust in the libraries you consume.

> You're misrepresenting the problem. There was never a bug or an issue The story originated from the author of this article [0] posting a bug report issue [1]. Why are you accusing others of misrepresenting the problem while doing so yourself? 0: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db… 1: https://archive.is/BEqfM

OpenVMS was promoted as ultrasecure back in the day. Hint: exploits happened too. Here's your hard slap in your face. https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable…

> Runs within the same VM with strong safety guarantees. You still generate code at runtime and there had been multiple Java vulnerabilities where features like "runtime code loading/generation" and "reflections" lead to RCE vulnerabilities. And sure you can RCE bytecode but so what, it's still code which can do anything your application can do. I.e. the same as you have with "unsafe" attack vectors. And while you could try to use the VM as a security sandbox it requires additional work and at lest for Java is known to not work well and if you do so you can also spend additional work to sandbox binaries... And then C#/Java libraries still do bind to C/C++ code, and their VM is still implemented in C/C++ and neither VMs are meant to be a sandbox to allow running untrusted code (both had some features for this, in both cases but especially Java it didn't work out well and by now both have dropped/deprecated it). > https://medium.com/@shnatsel/how-rusts-standard-library-was-... Sure, there had been a single bad security vulnerability in the standard library on stable. But so what. There had been more then one or two in fundamental parts of the JVM and probably for C#, too (IDK). In the end neither rust's unsafe nor Java's/C#'s VMs/GC are meant as security protection mechanisms. They are tools to make it easier to write correct code. And more correct code also means less security vulnerabilities. If you rely on any of them for security you already have lost. Which…

This situation is the sad and absurd result of two processes going on in the Rust community. The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of grief for the maintainer of actix and prevented real (but far overblown) code issues from being fixed in a productive way. But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust commmunity members are conflating two wildly different scenarios together. The first is a library exposing an API which, if used in an unlikely and contrived way, could result in a program using that library containing undefined behavior. Then, since that program has undefined behavior, it could contain a memory bug. If that were the case, someone could potentially exploit that bug to attack a user of that program. You'll notice this is a series of conditional statements - its a funnel of decreasing probability. So yes, library APIs which can allow UB in safe code - even unlikely and contrived safe code - must be fixed. The goal of Rust is that safe APIs can never cause UB. But people should have a proportionate understanding of the risk profile of these bugs (again: a programmer using this API in an unlikely way could create a program with a bug that could…

So let's assume the argument you're making is valid. ASLR is security theater because it protects against dumb attackers and fixing buffer overflows is the real solution. Let's ignore that only recently have languages become available that make it possible to do so for high-performance code. That's a straightforward problem to solve - we know how to rewrite code in other languages, we can build tools to help us do it effectively, etc. Let's also ignore that the recency of the languages mean that few people know how to code that effectively. We can train armies of engineers. Let's ignore that training engineers takes significant amounts of time & shifting massive industries is difficult. That will be solved over time. Lets ignore that Rust is more difficult to write than C/C++ - after all we're just converting existing code so that could be easier & the more time spent during writing is paid off by less time debugging at runtime. Let's also ignore that A LOT of money has been poured into existing software and a non-trivial amount would have to be donated/volunteered to migrate to languages where it's impossible. We have OSS volunteers and enthusiasts and corporate interests are aligned to sponsor conversions. Let's ignore that it takes time to integrate new languages into large corporations with existing build systems, infrastructure, tooling, etc. They'll solve that - again, interests are aligned here. Let's ignore ALL of those issues. XSS, Rowhammer, Meltdown,…