I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all.
I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what Actix does should use any unsafe code at all, so I didn't use it.
When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision.
There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.
I hit a same conclusion about a popular framework (that shall remain unnamed) on a different platform a few years back.
It feels like it should be simple: I disagreed with how the maintainer was doing things, so I decided the package was not for me. No need to hassle them about it. I wish it could be that simple.
Instead, I had to weather a fair bit of defending my choice to use a different, less popular option, and there's apparently no honest answer I can give that won't be taken as an attack on the framework or its users. And refusing to engage with the question is, of course, rude.
I'm finding that Internet culture wears me down, these days. Even when you don't go looking for flamewars, they come looking for you.
With less-popular libraries, it's easier. Open an issue, say hi, make sure the maintainer knows what you're planning on doing, do it, learn a few things, have a nice day. Once or twice I've been asked to more-or-less rewrite the patch because the maintainer didn't like something about my coding style, which is also fine, and often a good way to try a different way of doing things on for size. It's all pretty benign. But popular, well-known projects have this way of getting political.
I suspect that the worst thing that could possibly happen to one of my labors of love would be for lots of other people to like it, too. A few people, great. But I don't want my free time to become Internet politicized.
Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate.
Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it.
I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere.
They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.
I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit.
In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty.
The fact that the author deleted many of the linked issues e.g. https://github.com/fafhrd91/actix-net/issues/83 really feels like he is playing the victim here and taking everyone for a ride, denying his own responsibility in all this drama that's unfolded.
Yes a community should be open and forgiving, but blindly forgiving someone who doesn't even admit their own mistakes, who doesn't even understand what they are being forgiven for, is naive and also will result in community destruction.
I also don't buy the "if you don't like it just don't use it" argument. If it's actively dangerous and you know this, and you know that other people don't know this, you do have a responsibility to (politely) inform others about it. Simplying "not using it" is plain negligence.
[1] "the patch is boring", LOL WTF I would never have even come up with something this insulting even when I wanted to actively piss someone off, kudos for imaginativity
> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.
Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source.
Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited.
This is the standard voice vs. exit dilemma. Rust community is, for better or worse, very worried about "fracturing the ecosystem" so they generally prefer voice. Well, some of these voices can get ugly.
I'm curious what you'd recommend instead for async pgsql requirements as a Rust web framework. Actix seemed interesting, but I didn't know about the masses of unsafe. These too eliminate it, because it'd be able to crash/break a cluster that uses deliberate unsoundness for its serialization/deserialization needs in the vain of speed (timely-dataflow), allowing memory issues to spread (at least in theory)... I thus can't use a framework that uses this much unsafs/has known stray pointers or similar bugd/issues.
I have to question your position from a moral standpoint though.
If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...
> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.
It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.
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 do neither, but don't be surprised when people call you out on it.
> 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 entitlement looks like.
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.
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 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects?
You use it, you evaluate then accept the consequences.
You don't? Well Patch it.
You can't? Use an alternative.
Nothing else available? Fork it and fix it.
If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not helping, especially when slamming people working for free trying to solve it, even if not correctly or the way you'd like).
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.
If you use other peoples work for free and makes demands, then you should really stop using others free work and start paying for what you need.
It's your responsibility to choose what code you use, and unless the author has explicitly given specific guarantees they promise to uphold come hell or high water, it IS a toy project until proven otherwise.
It's such absolute nonsense to expect other people to submit to your wishes and whims without any compensation or prior consent.
But chastising someone in public for not submitting to your wishes?
Backing up another level...it’s concerning to me when a language relies heavily on single-maintainer libraries for commonly needed functionality.
If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and find a way to govern/maintain it the same way they maintain the rest of the project.
I think about this a lot with Racket lately. Some of the core packages that everyone uses for date/time, Markdown parsing, etc., were written by a single guy in his spare time, who a few months ago was making noises about quitting the language (so far so good though).
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.
More like you should be expected, as a user, to look at the code youre using and determine if it fits your set of criteria. If you dont think its updated enough, or the authors free labor isnt fast enough for your needs, then dont use it. You come off super entitled and arent the only one. This is the kinda stuff thats making me start my new projects closed source instead of open by default.
People reading your comment as entitlement really need to pay more attention to the last paragraph. People really need to stop bandying about "entitlement" as if it deflects any and all criticism.
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.
I'm sure both sides are being childish here. Users thinking they can abuse a dev because they know better, and devs deciding they'd rather take their ball and go home. No one looks good at the end of this situation.
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?”
The popularity of a project doesn't change it from "toy" or "personal" to "primary focus of developer's time". The developer might still only have so much time to spend on the project.
If you aren't satisfied with the code, fork it and fix it yourself. You are owed nothing. What right do people think they have to call someone out on it? Why do they feel entitled to other people's time and energy?
This seems to be a case of mismatched expectations.
Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.
So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right?
But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.
Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.
I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.
I do think it's legit to avoid libraries with a lot of unsafe code. I myself started avoiding actix after these situations. If folks had simply stopped using it, that would have been a fine outcome here. That's not what happened though.
I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I reas the article I sensed your explanation was probably the case. Did the many safety-making patches cause the performance to go down?
I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees ANY notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even that large and I've seen lots of in fighting to the point where I've had to lock threads. The skills required for you to run a successful open spruce project are the same skills required for you to run a business. You're going to need people skills and understand how to de-escalate situations because once the community is large enough, there will be a lot of culture conflicts. The main challenge with open source is that if you're not getting actively incentivized (Paid for me) to maintain something that's super popular, it's easy to abandon it when things get hard.
While I much appreciate Steve's work on Rust, this does seem a little high on drama and low on substance. Rust really does seem to be a nice language and here for the long haul so bumps in the road are opportunities for improvement rather than moments to sow seeds of doubt. From the link title, I thought that someone had died or that Rust was fundamentally broken, but:
- The internet will be the internet and that's, unfortunately, here to stay.
- Being a maintainer can be a less than thankless job and that's a bummer but also a fact.
- Reddit can be toxic, news at 11.
I had assumed that 'unsafe' was a rarely used aspect of the language (as it is in Haskell and as duck-punching is in Python). It seems necessary (to me). It might be used more often than it should be? Hmm. Okay a little unsafe-coverage tool should allow for quick assessment. Of course, FFI libraries will be heavy on unsafe but use them at your own risk...
All successful software projects pass through previously-small-problem-becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal to JIRA..."). I don't find Steve's melodramatic response to an opportunity to "level-up" to be particularly helpful.
I do think it'd be great to have an unsafeness analyzer (if there isn't one already) and to expose those values in cargo.rs. And to follow other safeness-flag recommendations in this discussion. Were those in-place or in-flight, most of TFA would have been "the internet has driven away the maintainer of a good project and that's not good".
Perhaps we can get at a deeper, more durable insight if we assume for a moment that most individual actors are well-intentioned, and that the described vitriol on one side and perceived stubbornness on the other is an externality of the unfortunate incentives (or lack thereof) that are parasitic on the open source community.
It's almost instinctual/natural to misjudge the popularity of any project for some false sense of security or acceptance. Just think about the numerous issues that plagued the Node community around NPM packages with large amounts of downloads and GitHub stars that turned out to be problematic.
For me the deeper insight here is that we all sort of want our cake and eat it too. Project maintainers/owners want the freedom and enjoyment of working in open source building fun and useful things without any explicit commitments, and that's fair and understandable especially without any formal compensation. And the users want to be able to have access to a growing collection of projects without having much skin in the game, i.e. paying for it.
This isn't a problem with people, this is a problem innate to open source, and the double-edged sword that it is.
I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people have come to rely on.
Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.
It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.
Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes.
It often feels like newcomers and zealots preaching the unsafe issue, too. I have to wonder if the Rust docs couldn’t better point out “the goal is less unsafes, but unsafes will exist - this is fine”. I know it kind of explains this already, but perhaps being more blunt?
Actix-web even with a few unsafe is still more sound than most frameworks IMO. I’ll take slightly better with crazy good performance over not better at all with no guarantees.
Also, look, the other problem is Reddit: I’m starting to think larger projects should squat their name there and redirect to better discussion places. I comment on Reddit sometimes and I roll my eyes every time I’ve done it lately.
This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of fame. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, please watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. Please watch the video!
The core problem is that fame used to be opt-in. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.
On the internet fame became something that happens to you, because the internet IS media access. We're used to seeing fame as something that was chosen; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means walking away from your normal life.
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.
This is very difficult. I feel badly for the author of actix-web, and I agree with Klabnik to the extent that Reddit can be a terrible place.
What I think this is, is a sad day for the Rust community.
But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily good¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.
But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.
Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.
¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being benevolent, and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.
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. Surely there are not hostile developers who would've been willing to take over the maintainer role.
I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...
This is an unfortunate, but I think necessary part of community growth. I really don’t think it’s possible to create a large community around a language that is business critical, and not have these kinds of setbacks where people get worked up and hurt each other’s feelings.
Python has many of the same issues, where core devs and key maintainers go dark or behave badly. What Python does do pretty well, and what I like about it, is placing its core user front and center. For Python, that is the beginning programmer, and Python has a lot of empathy for him or her. What I also like about Python is a general willingness to have difficult conversations and back rebuttals with code snippets.
I read difficult conversations by Bruce Patton a while back, and it wasn’t an easy read for me because I have problems of responding sometimes in a constructive manner, but I learned a lot and I would highly recommend it .
I’m confident the Rust community will survive this and come out stronger than ever :)
To sum it up: "George R.R. Martin is not your bitch."
I would carry this even further: "Open source maintainers are not your bitch."
I see a lot of whining and entitlement from engineers on open source repo issues pages. Open a pull request, fork it and host it yourself, and just relax in general.
Not to say maintainers can't be jerks. But again: That is their choice. They are not your bitch.
This is a sad day for Rust. Situations can spiral out of control. Who started it? Who escalated it? You can't really define these because communication is sloppy and difficult, especially when there are cultural and language barriers involved. The only way to not get these situations to spiral out of control are a thick skin, forgiveness, and assuming noble intent.
There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.
I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.
Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).
I really want to like Rust. Every time I try to use Rust on a project, I end up down a rabbit hole of internet arguments and unnecessary drama. When I finally give up on Rust, I find I can accomplish the same task in a fraction of the time with a more mature language. At this point, I think Rust is best reserved for very narrow use cases that can be shown to fit neatly within Rust's current ecosystem before coding begins.
Rust is a macrocosm of a phenomenon I've noticed in my own career: My productivity is inversely proportional to how dogmatically "correct" I'm trying to be with my implementation. The Rust community embodies many of the negative aspects of perfectionism that tend to stall real world progress. That perfectionism doesn't necessarily carry over to your code, but I find myself wondering if I'm doing things "the right way" far more in Rust than other languages.
Some growing pains are normal for any community. I really hope the Rust community can settle into a healthy environment. Until then, I'll reserve Rust for only smaller projects where I can afford to bail and rewrite in another language if it starts to spiral in complexity.
[+] [-] dang|6 years ago|reply
[+] [-] _-___________-_|6 years ago|reply
I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what Actix does should use any unsafe code at all, so I didn't use it.
When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision.
There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.
[+] [-] mumblemumble|6 years ago|reply
It feels like it should be simple: I disagreed with how the maintainer was doing things, so I decided the package was not for me. No need to hassle them about it. I wish it could be that simple.
Instead, I had to weather a fair bit of defending my choice to use a different, less popular option, and there's apparently no honest answer I can give that won't be taken as an attack on the framework or its users. And refusing to engage with the question is, of course, rude.
I'm finding that Internet culture wears me down, these days. Even when you don't go looking for flamewars, they come looking for you.
With less-popular libraries, it's easier. Open an issue, say hi, make sure the maintainer knows what you're planning on doing, do it, learn a few things, have a nice day. Once or twice I've been asked to more-or-less rewrite the patch because the maintainer didn't like something about my coding style, which is also fine, and often a good way to try a different way of doing things on for size. It's all pretty benign. But popular, well-known projects have this way of getting political.
I suspect that the worst thing that could possibly happen to one of my labors of love would be for lots of other people to like it, too. A few people, great. But I don't want my free time to become Internet politicized.
[+] [-] kbenson|6 years ago|reply
Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it.
I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere.
They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.
[+] [-] infinity0|6 years ago|reply
In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty.
The fact that the author deleted many of the linked issues e.g. https://github.com/fafhrd91/actix-net/issues/83 really feels like he is playing the victim here and taking everyone for a ride, denying his own responsibility in all this drama that's unfolded.
Yes a community should be open and forgiving, but blindly forgiving someone who doesn't even admit their own mistakes, who doesn't even understand what they are being forgiven for, is naive and also will result in community destruction.
I also don't buy the "if you don't like it just don't use it" argument. If it's actively dangerous and you know this, and you know that other people don't know this, you do have a responsibility to (politely) inform others about it. Simplying "not using it" is plain negligence.
[1] "the patch is boring", LOL WTF I would never have even come up with something this insulting even when I wanted to actively piss someone off, kudos for imaginativity
[+] [-] kragen|6 years ago|reply
Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source.
Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited.
I've written a bit about the history of some such friendly forks at https://news.ycombinator.com/item?id=22080672
[+] [-] dunkelheit|6 years ago|reply
[+] [-] C14L|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] namibj|6 years ago|reply
[+] [-] munmaek|6 years ago|reply
[+] [-] p1esk|6 years ago|reply
So in that case you wouldn’t use any software written in plain C, right?
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] strbean|6 years ago|reply
If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...
[+] [-] bachmeier|6 years ago|reply
It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.
[+] [-] vunie|6 years ago|reply
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 do neither, but don't be surprised when people call you out on it.
[+] [-] manish_gill|6 years ago|reply
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 entitlement looks like.
[+] [-] oefrha|6 years ago|reply
Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.
[+] [-] ginko|6 years ago|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 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
[+] [-] Ragnarork|6 years ago|reply
You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it.
If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not helping, especially when slamming people working for free trying to solve it, even if not correctly or the way you'd like).
[+] [-] protomyth|6 years ago|reply
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.
[+] [-] lostmyoldone|6 years ago|reply
If you use other peoples work for free and makes demands, then you should really stop using others free work and start paying for what you need.
It's your responsibility to choose what code you use, and unless the author has explicitly given specific guarantees they promise to uphold come hell or high water, it IS a toy project until proven otherwise.
It's such absolute nonsense to expect other people to submit to your wishes and whims without any compensation or prior consent.
But chastising someone in public for not submitting to your wishes?
That's straight up bullying.
[+] [-] velcrovan|6 years ago|reply
If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and find a way to govern/maintain it the same way they maintain the rest of the project.
I think about this a lot with Racket lately. Some of the core packages that everyone uses for date/time, Markdown parsing, etc., were written by a single guy in his spare time, who a few months ago was making noises about quitting the language (so far so good though).
[+] [-] bla3|6 years ago|reply
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.
[+] [-] mumphster|6 years ago|reply
[+] [-] Karunamon|6 years ago|reply
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.
[+] [-] clarry|6 years ago|reply
People who write security sensitive toys and don't care enough to vet their deps?
Professionals who profit off security sensitive programs written on top of others' free work without paying a dime?
I don't think either group is in a position to make such demands.
[+] [-] blackearl|6 years ago|reply
[+] [-] ixtli|6 years ago|reply
[+] [-] cmiles74|6 years ago|reply
[+] [-] andonisus|6 years ago|reply
[+] [-] trunnell|6 years ago|reply
Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.
So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right?
But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.
Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.
I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.
[+] [-] steveklabnik|6 years ago|reply
[+] [-] travisgriggs|6 years ago|reply
[+] [-] joeblau|6 years ago|reply
[+] [-] CoffeeDregs|6 years ago|reply
- The internet will be the internet and that's, unfortunately, here to stay.
- Being a maintainer can be a less than thankless job and that's a bummer but also a fact.
- Reddit can be toxic, news at 11.
I had assumed that 'unsafe' was a rarely used aspect of the language (as it is in Haskell and as duck-punching is in Python). It seems necessary (to me). It might be used more often than it should be? Hmm. Okay a little unsafe-coverage tool should allow for quick assessment. Of course, FFI libraries will be heavy on unsafe but use them at your own risk...
All successful software projects pass through previously-small-problem-becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal to JIRA..."). I don't find Steve's melodramatic response to an opportunity to "level-up" to be particularly helpful.
I do think it'd be great to have an unsafeness analyzer (if there isn't one already) and to expose those values in cargo.rs. And to follow other safeness-flag recommendations in this discussion. Were those in-place or in-flight, most of TFA would have been "the internet has driven away the maintainer of a good project and that's not good".
[+] [-] gmaster1440|6 years ago|reply
It's almost instinctual/natural to misjudge the popularity of any project for some false sense of security or acceptance. Just think about the numerous issues that plagued the Node community around NPM packages with large amounts of downloads and GitHub stars that turned out to be problematic.
For me the deeper insight here is that we all sort of want our cake and eat it too. Project maintainers/owners want the freedom and enjoyment of working in open source building fun and useful things without any explicit commitments, and that's fair and understandable especially without any formal compensation. And the users want to be able to have access to a growing collection of projects without having much skin in the game, i.e. paying for it.
This isn't a problem with people, this is a problem innate to open source, and the double-edged sword that it is.
[+] [-] dashwav|6 years ago|reply
Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.
It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.
[+] [-] Klonoar|6 years ago|reply
Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes.
It often feels like newcomers and zealots preaching the unsafe issue, too. I have to wonder if the Rust docs couldn’t better point out “the goal is less unsafes, but unsafes will exist - this is fine”. I know it kind of explains this already, but perhaps being more blunt?
Actix-web even with a few unsafe is still more sound than most frameworks IMO. I’ll take slightly better with crazy good performance over not better at all with no guarantees.
Also, look, the other problem is Reddit: I’m starting to think larger projects should squat their name there and redirect to better discussion places. I comment on Reddit sometimes and I roll my eyes every time I’ve done it lately.
End rant, I guess.
[+] [-] pdkl95|6 years ago|reply
This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of fame. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, please watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. Please watch the video!
The core problem is that fame used to be opt-in. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.
On the internet fame became something that happens to you, because the internet IS media access. We're used to seeing fame as something that was chosen; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means walking away from your normal life.
[1] https://www.youtube.com/watch?v=PmTUW-owa2w
[+] [-] mtalantikite|6 years ago|reply
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.
[+] [-] AaronFriel|6 years ago|reply
What I think this is, is a sad day for the Rust community.
But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily good¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.
But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.
Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.
¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being benevolent, and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.
[+] [-] spamizbad|6 years ago|reply
[+] [-] AdmiralAsshat|6 years ago|reply
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. Surely there are not hostile developers who would've been willing to take over the maintainer role.
[+] [-] transect|6 years ago|reply
https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...
I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...
[+] [-] yingw787|6 years ago|reply
Python has many of the same issues, where core devs and key maintainers go dark or behave badly. What Python does do pretty well, and what I like about it, is placing its core user front and center. For Python, that is the beginning programmer, and Python has a lot of empathy for him or her. What I also like about Python is a general willingness to have difficult conversations and back rebuttals with code snippets.
I read difficult conversations by Bruce Patton a while back, and it wasn’t an easy read for me because I have problems of responding sometimes in a constructive manner, but I learned a lot and I would highly recommend it .
I’m confident the Rust community will survive this and come out stronger than ever :)
[+] [-] honkycat|6 years ago|reply
To sum it up: "George R.R. Martin is not your bitch."
I would carry this even further: "Open source maintainers are not your bitch."
I see a lot of whining and entitlement from engineers on open source repo issues pages. Open a pull request, fork it and host it yourself, and just relax in general.
Not to say maintainers can't be jerks. But again: That is their choice. They are not your bitch.
[+] [-] epage|6 years ago|reply
There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.
I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.
Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).
[+] [-] PragmaticPulp|6 years ago|reply
Rust is a macrocosm of a phenomenon I've noticed in my own career: My productivity is inversely proportional to how dogmatically "correct" I'm trying to be with my implementation. The Rust community embodies many of the negative aspects of perfectionism that tend to stall real world progress. That perfectionism doesn't necessarily carry over to your code, but I find myself wondering if I'm doing things "the right way" far more in Rust than other languages.
Some growing pains are normal for any community. I really hope the Rust community can settle into a healthy environment. Until then, I'll reserve Rust for only smaller projects where I can afford to bail and rewrite in another language if it starts to spiral in complexity.
[+] [-] CoffeePython|6 years ago|reply
Can someone familiar with Rust and it’s communities explain from a high level what all this is about?