341–350 of 1001 posts
Tried reading through this but without context it’s very unclear what has happened. Can someone familiar with Rust and it’s communities explain from a high level what all this is about?
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/
Earlier quoted context omitted.
> 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 ma…
Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...
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…
> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…
So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one.
With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using.
This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.
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…
You are, of course, free to write whatever unsafe, insecure code you want. You are, by leaving the issue tracker in Github enabled, inviting public feedback on the quality of the code you write.
When you implicitly rescind that invitation by closing issues demonstrating concrete safety problems, people are well within their rights to call out the safety issues in the project as well as your violation of reasonable expectations and community norms. And don't bother posting the "warranty disclaimer" from FOSS licenses, that's not what anyone was ever talking about.
Deleting the entire project as he did is an incredibly petty and immature response. If he just wanted to quit, the project could have been archived (made read-only) and marked unmaintained.
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…
Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!
Earlier quoted context omitted.
> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.
> Sure, but that DOES NOT mean you're immune to criticism The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer. You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer. Everything else is just trying to force peop…
> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.
> Everything else is just trying to force people to do stuff for you, and that's rude.
Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.
You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.
It's easy to get any bug fix you want: pay for them. If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you. (Unfortunately, I can see from reading the comments that not everyone is getting it.) Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long…
Each issue could have a donate button. The bounty would be split to the authors that contributed, with some remainder left for unfinished work (documentation, unit tests, etc).
To settle how the bounty is split for multiple authors, they could go through an anonymous round of "bids" to propose splits, with the bounty locked until they agreed. Maybe the maintainer/reporter able to settle disagreements by choosing a split ratio that lain somewhere between the range of those bid on.
This is generally a bad thing. It leads to NIH, to poor portability, to difficult integration in other dev environments etc... But it does mean that you carefully consider every dependency that you must use. The quality of the packaging is often an indication of the quality of the code too, a well polished build system inspires confidence, a crappy buggy bespoke shell script less so.
Meanwhile take this example: I've re-started working on a PlayStation emulator a few weeks ago. I haven't reached the point where I need to display images or output sound, it's pure algorithmic code with no I/O so far. That's 0 dependencies.
But then I wanted to add some basic logging infrastructure to be able to do 'warn!("this thing shouldn't happen")' or 'debug!("this register has value {:x}", val")'. I could just use println! but, hey, adding dependencies is super easy and I'll end up with more flexible and expressive code, so let's do that instead. So I add these two lines to my Cargo.toml (note the simple in simple_logger):
[dependencies]
log = "0.4"
simple_logger = "1.3.0"
Compiling autocfg v0.1.7
Compiling libc v0.2.66
Compiling log v0.4.8
Compiling lazy_static v1.4.0
Compiling cfg-if v0.1.10
Compiling num-traits v0.2.10
Compiling num-integer v0.1.41
Compiling atty v0.2.13
Compiling time v0.1.42
Compiling colored v1.9.0
Compiling chrono v0.4.10
Compiling simple_logger v1.3.0
Oh and beyond that Reddit is a terrible place that manages to be the worst of 4chan and the worst of Facebook in one convenient package and should be avoided at all costs, but we already knew that.
Earlier quoted context omitted.
You are correct. That doesn't mean that people will incorrectly interpret it, though.
Ada’s language is probably clearer and less loaded: checked and unchecked.
The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)