Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

71–80 of 1001 posts

Re: A Sad Day for Rust

#71

Post by coleifer »

vunie wrote: 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…

How about instead of pushing the responsibility on someone else, you take responsibility for YOUR security-sensitive context and do the research before you start installing libraries?

Re: A Sad Day for Rust

#72

Post by ixtli »

vunie wrote: 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…

what code does not run in a “security-sensitive context”? who’s responsibility is it really? The person who wrote the code with a disclaimer saying they were presenting it to you AS-IS? Or the person who’s choosing to run the code in the “security-sensitive context?”

Re: A Sad Day for Rust

#73

Post by dashwav »

ddevault wrote: post #38

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. And regardless of how strongly you feel about 2), 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". These statements aren't mutually exclusive

Re: A Sad Day for Rust

#74

Post by jwlake »

adar wrote: post #50
manish_gill wrote: post #26

Earlier quoted context omitted.

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.

I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares?

If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?

Re: A Sad Day for Rust

#76

Post by SpicyLemonZest »

spamizbad wrote: post #60
steveklabnik wrote: post #30

Earlier quoted context omitted.

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.

Ah, point taken. But perhaps it’s better in situations like this where the original maintainer feels harangued by the community?

Forking someone’s project because they won’t accept your PRs will definitely make them feel harangued by the community. I’m not sure if it necessarily has to be that way, but creating a hostile fork is conventionally considered very rude.

Re: A Sad Day for Rust

#77

Post by jessaustin »

adar wrote: post #50
manish_gill wrote: post #26

Earlier quoted context omitted.

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.

In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.

Re: A Sad Day for Rust

#78

Post by ixtli »

coleifer wrote: post #71
vunie wrote: 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…

How about instead of pushing the responsibility on someone else, you take responsibility for YOUR security-sensitive context and do the research before you start installing libraries?

exactly. the dev has to take responsibility for what they write but there’s no responsibility required when you run something??

Re: A Sad Day for Rust

#79

Post by rhodysurf »

ddevault wrote: post #38

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…

As someone who works for a dod contractor this whole situation sounds crazy. Just because something is available as a crate doesnt mean you are to assume it safe or appropriate for your use. The onus of verifying the dependencies should always be on the consumer.

Re: A Sad Day for Rust

#80

Post by stanferder »

endothrowho333 wrote: post #21

> “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…

It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself:

1) [T]he Rust project saw Rust as more than just the language...

2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name.

If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that cause fervently.

And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.

People who perceive themselves to be defending a cause against danger are going to react very strongly, much more so than people who are criticizing an implementation choice on purely technical grounds.

Post reply on HN