Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

81–90 of 1001 posts

Re: A Sad Day for Rust

#81

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

Exactly this. If it doesn't meet your standards, don't use it. Alternatively, go fork yourself.

The only time ever on earth where a homophone actually has been done well. Thank you.

Re: A Sad Day for Rust

#82

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

Exactly this. If it doesn't meet your standards, don't use it. Alternatively, go fork yourself.

Personally I plan to vendor all dependencies.

It would be nice to have cargo/rustc support 'allow_unsafe' per module and also for dependencies, so you know you have to review a dependency really well.

Re: A Sad Day for Rust

#83
post #73

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library.…

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care"

Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.

Re: A Sad Day for Rust

#84
A few years back I started using Rust after spending many years working with Go full-time and the first thing I noticed was that the team really focused on only providing the language, that libraries like HTTP were being pushed out to the community to contribute. It's a totally fair position for a language to take, but I found it disappointing coming from Go where I knew I could just use 'net/http' and move on to solving problems.

This is the first I've heard of this conflict in the Rust community, but honestly it's not at all surprising. People write lots of web servers and if you're relying on your community to provide critical libraries (http is pretty critical in 2020) things like this are bound to happen. I really wish Rust core could provide a standard library of tools more akin to Go as I really enjoyed working with it when I was learning it.

Re: A Sad Day for Rust

#85
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

According to https://github.com/actix/actix-web, it appears that the author did accept the security concerns (when an actual use-after-free was found, but maybe not the previous, generic “unsafe oh noz” shitstorms), and wanted to explore some other way to fix the problem instead of accepting the patch as is.

Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.

Re: A Sad Day for Rust

#86
post #51
post #16

Earlier quoted context omitted.

I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

A similar disclaimer is contained in the GPLv2 and therefore applies to the Linux kernel. Does that mean we can not impose any expectations regarding security on its maintainers either? Why can't we have legal disclaimers like this so that the legal system with its tech-oblivious case law and multi-million-dollar penalties is prevented from interfering while also retaining softer sanctions such as the threat of commu…

> Does that mean we can not impose any expectations regarding security on its maintainers either?

Yes. If you want a secure version of Linux, pay a vendor like Red Hat who’s willing to provide those assurances.

Re: A Sad Day for Rust

#87

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

> Generally, the type of person to post on Reddit frequently enough, has social cohesion problems that may preclude him from fulfilling his social needs through more healthy avenues, like real life.

You mean like making sweeping generalisations about a platform with millions of users?

Re: A Sad Day for Rust

#88
post #17

Earlier quoted context omitted.

You can take a look at the actix-web repo, which has been wiped. A message has been added: https://github.com/actix/actix-web/

Repo wiped after receiving criticism. I think I'm beginning to see another side to the story other than reddit being a swarm of jerks.

I'm not sure you can consider "It’s extra nasty this time. Some people go far, far, far over the line." to just be criticism.

What does it say that I wouldn't be surprised one iota if "far, far, far over the line" included death threats? Nobody should be expected to continue to contribute in a community with that kind of vitriol pointed their way.

EDIT: Even if all "far, far, far over the line" means is personal attacks and not death threats, that is still not simply criticism, and it's still far beyond what someone should be expected to endure in the name of "open source".

Re: A Sad Day for Rust

#89
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 potentially be exploitable). This is a miniscule increase in the risk of another heartbleed, it is not the same thing as heartbleed.

The spark that lit the kindling of the toxic Reddit community was a blog post by Shnatsel, a member of the RustSec team. This blog post didn't get attention here, but I want to take a moment to look at how ridiculously it frames things by examining its analysis of a different project: reqwest (sort of the most standard HTTP client library in Rust).

Here's the link: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

The fuzz test, which is what the library is about, found no security issues. It found some hangs in 6% of cases and Shnatsel traces them to a known deadlock issue. This is a great result.

But Shnatsel spends most of this talking about a custom hashmap implemented in the http library, which the RustSec group did a security audit of just a few months ago. That security audit found only two issues, both UB that would result from a contrived use of a minor library API (they are linked in the blog post, but not explained). These two issues were fixed, and the fix released, by the maintainers of the http crate in 10 days.

This is an incredible success! The security audit of a foundational library found two minor issues which were promptly fixed, and the fuzz confirms that the entire stack on top of it seems to contain no memory issues. Wonderful result, but how does Shnatsel frame this?

> First things first: it didn’t segfault! I am actually impressed because I had really low expectations going into this.

Come on! The blog post is full of these kinds of snide zingers which are totally unfounded in the face of the actual evidence presented. When you have someone writing in this disingenuous, meanspirited way about open source maintainers and then putting this in front of a groupthinking rage machine community like Reddit, of course you're going to get harassment. This behavior is totally unacceptable, and it's very sad to see it promoted in the Rust community.

Re: A Sad Day for Rust

#90

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would have liked to read the author's thoughts about "why."
Post reply on HN