Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

101–110 of 1001 posts

Re: A Sad Day for Rust

#101
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…

If you're a developer of an open-source project and people start using that, it's on the users to verify that the project is security-conscious.

I open-source lots of my fun hacks for free in the hope that they're useful for someone, but I'm not going to do free unfun work just because someone decided to use my hack in production.

Users of open-source software are acting way too entitled.

Re: A Sad Day for Rust

#102

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…

I wish I could up-vote this 1000 times.

Re: A Sad Day for Rust

#103
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…

No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.

Looking at the postmortem[1], it looks like the patches provided were not good enough in the developer's eyes:

I believed it held mutable aliasing invariant and I was very happy that someone found real problem. I wanted to solve the problem, just with a bit of creativity. And use RefCell solution only if it would be not possible to solve it with any other way. Btw, I like the solution I found, it is in master and solves the problem at least one from the issue. If you want to push boundaries you have to touch this boundaries and sometimes you push too hard.

That sounds very much like the developer was headed to fixing them, but I guess the harassment and need for now won.

Re: A Sad Day for Rust

#104

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…

The best justification for this attitude is that it's the most encouraging of open source development. Other attitudes raise the cost of open source development -- considering that it's already a losing proposition (w.r.t. lost time + opportunity) -- and will result in less quality open source software. People just won't put the work in if all they get back is this entitled bullshit.

Re: A Sad Day for Rust

#105

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

> Forking is extremely aggressive

Shouldn't we disabuse ourselves of that notion? Forking a project to solve an issue is just that. We shouldn't attach any sort of emotional connotation to it.

Re: A Sad Day for Rust

#106
I think this has less to do with Rust and more to do with people using the Web as a tool to be unkind to what they think are unhuman pixels.

Sometimes I think the Web was a mistake, and that none of us are ready for the scale that it brings.

Re: A Sad Day for Rust

#107

The larger pity, to me, seems to be the maintainer's decision to not only quit the project, but to take down the repo with the intent to delete it: https://github.com/actix/actix-web I get it, they feel personally harassed and slighted. And it's their project, they can do with it what they like. But it still feels like the decision is motivated more by spite than by a desire to simply wash one's hand of the project.…

It got moved to their personal github account, not deleted.

He said he is going to move it to private in his [post mortem](https://github.com/actix/actix-web)

Re: A Sad Day for Rust

#108

Earlier quoted context omitted.

I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.

This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.

All of this is second hand, where are the mean comments "making" this person quit their own project?

Were they actual personal attacks, or just criticism of the code?

If you can't accept legitimate criticism of your work, that shows a real lack of maturity.

(The article didn't give concrete examples, so I don't know which is the case here.)

Re: A Sad Day for Rust

#109
1. I find the assumption that Rust code is safe a bit overly optimistic. If you're writing network-facing code, security is always an issue to some extent, even if mitigated by language guard-rails.

2. The actix framework author supposedly did the following things at once:

   2.1 Wrote code somewhat carelessly
   2.2 Wrote and maintained his code alone
   2.3 Claimed his code was "safe" - in that mythical complete sense I mentioned above
this combination is a recipe for disaster, and he was warned (albeit in a possibly-non-friendly-way). Thus, while the public outroar is probably excessive - security bugs do happen - he is to some extent getting what's coming to him.

Caveat: I'm a C++ person and am not familiar with the Rust ecosystem.

Re: A Sad Day for Rust

#110
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's response might be valid if it were limited to that. But, quoting TFA, they went beyond that.

"It’s extra nasty this time. Some people go far, far, far over the line."

When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.

Post reply on HN