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
> 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.
Yes, nice comments such as
>seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?
> 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.
Forking if it's mature and featured enough to justify it, but it maybe too unsafe broken to invest in rewriting large swaths of code. That's the perpetual trade-off of engineering decisions; whether to build, fork or buy.
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.
We just use hyper directly, with a small amount of glue code to use serde_json, serde_urlencoded for body parsing and a very simple (and very fast) router of our own creation. This approach also made it very simple for us to introduce std-future/async-await in a gradual way.
I've been in the process of switching to tonic for the last few of weeks. Based on hyper/tower and has async/await support. It's a gRPC server rather than HTTP, so I've been using it with grpc-gateway to provide an HTTP OpenAPI v2 interface.
It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate:
- Rust server request/response types and request handler stubs.
- grpc-gateway files and an OpenAPI v2 json spec.
- Client side typescript types and request/response handlers from the OpenAPI spec.
So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.
At the risk of projection, that comment reads to me as an attempt at playing gotcha.
It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to.
Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place.
That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.
It is actually easier to introduce an undefined behavior in unsafe rust than in C, since rust use the guarantee that two mutable references living that the same time cannot aliase to optimize code.
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...
This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.
In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)
> 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 think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you.
Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled.
I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.
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.
The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it.
This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve!
I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.
Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue.
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.
>People could have forked and worked on the issues themselves, but that's asking too much.
Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag.
>Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either.
>Your comment is precisely what entitlement looks like.
This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past.
Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too.
I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't.
If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.
If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following.
It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.
From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist.
If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.
Although I agree with you but there is one more point to consider. Why do people write open source libraries/frameworks? You'd say they write it as a hobby or learning experience and this is totally fine. But why don't they keep their work private if they aren't or shouldn't be bothered about how people use their libraries?
I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects.
But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.
Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good.
I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud.
I'm not familiar with actix so I wont presume to say which category it falls into.
Reasonable expectation does not equate to entitlement.
So what is the person who finds the flaw supposed to do:
1. announce to all the other users of the library to download his branch with just the single fix
2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later.
TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.
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!
> It's not like he was getting paid to work on this, was it?
So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?
No demand for work is being made here. I'm simply saying a project that isn't a toy project will be criticized if it doesn't behave according to community standards.
I'd consider it to be social norms. It certainly isn't entitlement.
> It's not like he was getting paid to work on this, was it?
That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely.
Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.
Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.
Open source is like capitalism. But a project's success is measured in commitment instead of capital.
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.
IANAL but I'm fairly certain this protects you against legal action and not negativity on the internet.
Furthermore, if we're to interpret this clause as "do not place any trust in this software whatsoever" then I guess that's really bad news for the security community at large.
We're not expecting a warranty and we're not asking for damages.
It's not really surprising that the Rust community is made out of people who've chosen to take extra effort in security, and that they wouldn't tolerate a cavalier attitude to it. It's disappointing that this was expressed in an unconstructive way.
> 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
This is a really bad answer because the most reliable and robust free software projects out there all use this same boilerplate license warnings. This is just for legal protection.
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 community ostracism/obnoxious messages to incentivise some degree of quality?
OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees".
There is a difference between "Hey, this is a silly side project so definitely use at your own risk, as far as I'm concerned its a place for me to learn and should be treated as a toy" and "Hey, I think this is worth your time, you should use this in your production stack, and obviously I've set up legal protections so you can't sue me if something goes wrong, but I am trying to push this as something lots of people should use and trust".
If someone walks into my house and tries cookies I'm clearly learning how to make and then throws up, that's very different than me putting up a big "FREE AMAZING BETTER COOKIES" sign on the sidewalk and handing them out and having people throw up. In both scenarios, the cookies are free! What are you blaming me for! How entitled! In the first, I think that position is more defendable. In the second, ehhh.....
For the record -- I'm not super familiar with this project, but I think that a lot of people don't consider the ramifications of being successful sometimes: your project could be used by a big company and lead to people's information getting hacked (and those people had nothing to do with any of these decisions). The only thing asked is to be upfront that this is not intended for that, as opposed to the temptation of calling your thing the best and telling everyone to use it. In the run up of a project, I think it's easy to forget that and get really hyped on showing how your thing is better than some incumbent for example. Just something to keep in mind.
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).
The thing that changed is we began building off of more and more open source, and so it became more and more important. Nobody is expecting a project's original creator to slave over it eternally. They are instead expecting them to clearly signal their intentions. A "Not Maintained" flag, or "Read my design philosophy before using", after understanding community expectations, is no effort and a reasonable expectation. Counter arguments like to think we are islands and that because we never signed an official contract, we have no responsibilities to anyone but ourselves. But that is not how society ever has or ever will work, and there never has nor ever will be any such thing as "leaving" society (other than death). There's a social contract that you are (unwillingly) a part of, and that's reality. Entitlement here is merely people implicitly recognizing that fact.
EDIT: This rant is a general reply to your general sentiment, not a specific reply to this particular case. I have no idea whether the author did in fact signal appropriately their design, risk, etc.
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.
Maybe that is what the developer intended, but afaik it is not what he communicated. What he communicated was a flat out dismissal of the issue along with the proposed fixes. Followed by deleting the whole issue from GitHub. To be fair, there were some very unpleasant things said in there, but he could have just deleted those and maybe locked the conversation telling people about his plans.
This whole thing was a feedback circle of increasing hostility between the community/contributors and this developer. At some points the developer was very unresponsive, leading to disappointment from the community, but then some very uncalled for personal attacks came from the community. I think the developer received some justified criticism, but I still understand his perspective, putting work in and getting abuse back sucks.
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).
The developer actively fought against this for a very long time, even before the reddit shit storms. Yes the community could have forked the project and started independent development.
I'd argue that forking and developing independently of the developer is as big of a middle finger as a developer taking their ball and going home. It just depends on who is on the receiving end.
I don't think either side is right here, but I don't think creating a public fork and building a community around that is an unbiased and neutral response either and should only be done in extreme circumstances... Which is does seem like what happened here.
I like the direction .Net is attempting to go here: there is a foundation and if you want your project to be taken seriously, you should join it. You still get to maintain your project (mostly) the way you want to, but if you stop maintaining the project, the foundation will take over.
(.Net is probably not unique in this regard, but it's what I'm familiar with.)
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 generally agree, except for this part: "Deleting the entire project as he did is an incredibly petty and immature response."
If he no longer wants to participate in the community, then deleting the repo was a good decision. It's not like the code is actually gone, other people have copies of it, and now that the original repo is gone nobody will mistakenly go to his repo and find it abandoned. It's basically the equivalent of boarding up the windows before you abandon a building.
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.
Taking the ball home when other kids abuse or bully you is correct action.
That is actually one of the things we teach the kids who are in these situations to do. It is ok to have a boundary, it is ok to leave the situation and it is ok to stand your ground. You don't ask for abuser validation nor permission.
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?
("bear the brunt" It's one of those weird words that only exists now in that phrase. Brunts are borne but otherwise unmentioned. It's kinda like how you can be over- or underwhelmed, but never just whelmed.)
Why should a project author dictate in what contexts their project can be used? It's on the coder to manage their dependencies and ensure they are a good fit for their needs... not the project author.
And what exactly are you contributing to this project author to match your demands of them immediately fixing flaws that are found?
> you either be receptive to security concerns or you clearly label your project as a toy project.
Or, assume all OSS projects are toy projects unless stated otherwise.
Usually the serious ones offer a support license for a fee, or are supported financially by companies. Otherwise, it's just someone building cool stuff for free.
Also, it's probably fair that most OSS maintainers aren't marketing their projects too aggressively outside of a blog post or a Reddit submission. When they take off, it's usually other developers hyping them and that hype usually comes from being lightweight, easy to configure or super fast. It's not until a project has been hyped by the community do people start trying to put it into production and looking into security issues.
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?
This. The project is considered one of the (if not the) go-to web frameworks in Rust, lives under its own organisation, is promoted and discussed by many other people. It's not a sole property of the maintainer any more. The maintainer does not owe anyone any new code, nor accepting any PRs. But he does have to set correct expectations. If you want to be the sole BDFL and not care about others opinions or contributions then don't promote it as production code, keep it under your own profile, and/or make it clear in the README. Now it's a community project, "fun" is not necessarily the most important quality anymore. State your position early.
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?
Not so much mutually exclusive as "safe, fast, easy, pick two", at least sometimes. It can take a lot of design effort to come up with a safe and efficient way to do some things, so it's often tempting to do something unsafe and efficient and hope it works out.
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.
It must depend on the project in ways I don't understand. Certainly while working on Firefox I saw tons of toxic behavior from users, and sometimes potential contributors. I've seen it in lots of other projects that I haven't worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish I could explain the difference, but I can't.
rr is only useful to people with a minimal level of knowledge, and in most cases to people who have stood in your shoes. Firefox is useful to any six-year-old with a cellphone. Maybe that explains the difference.
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.
You're right in the sense that, at the end of the day, almost every organizational/social structure is made of people. The interesting thing for me is to see what incentive structures are at play that incentivize otherwise good people to do apparently bad things.
We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.
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.
If people come to rely on your project, you are not more responsible.
I've been in the business since before open source was much of anything but a dream, and frankly, I wish a lot of more people would shutter their projects when/if they face these kinds of unreasonable expectations.
The vitriol and entitlement towards maintainers is sickening at times, and unless those affected close the doors, I'm afraid it'll continue to be ignored, and maintainers will continue to burn out.
Burn out is a real problem in the industry, and we really shouldn't help burn people out when it comes to work they do for free!
The problem is that people didn't choose Actix only for performance. I personally haven't used Actix, but it seems that all other contenders were lacking in some way, not only performance but also feature sets and flexibility and easiness. And thus we are now left with a horde of safe but otherwise lacking libraries instead of what could possibly be the best of breeds.
That's entirely fair - and I wasn't saying that choosing actix was a bad choice at the time for the users - but I also think that the people who were willing to contribute to Actix to make it safer are probably also the type of people who are willing to contribute to those other libraries to make them more useful.
If there is one trend that has been consistent in the development world it has been that there are always people willing to keep iterating on libraries to get better and better implementations.
Well a lot of the reason other rust web frameworks were lacking was that actix-web was so dominant in the space. If the actix-web project is indeed dead, some other projects (such as warp/tower) will get more attention and hopefully become more feature-complete.
Readit News
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.
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.
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.
Deleted Comment
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
Yes, nice comments such as
>seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?
and
> Never write rust code again
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
Deleted Comment
It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate:
- Rust server request/response types and request handler stubs. - grpc-gateway files and an OpenAPI v2 json spec. - Client side typescript types and request/response handlers from the OpenAPI spec.
So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.
Hopefully gotham or rocket gets around to updating.
Deleted Comment
So in that case you wouldn’t use any software written in plain C, right?
It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to.
Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place.
That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.
Deleted Comment
Deleted Comment
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...
This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.
In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)
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.
Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled.
I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.
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.
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.
https://medium.com/@shnatsel/smoke-testing-rust-http-clients...
Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article.
Here is the first one I clicked on:
https://github.com/algesten/ureq/issues/24
The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it.
This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve!
I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.
[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...
[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...
Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag.
>Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either.
>Your comment is precisely what entitlement looks like.
This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past.
Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too.
I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't.
If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.
It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.
If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.
I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects.
But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.
I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud.
I'm not familiar with actix so I wont presume to say which category it falls into.
So what is the person who finds the flaw supposed to do:
1. announce to all the other users of the library to download his branch with just the single fix
2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later.
TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.
Deleted Comment
So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?
I'd consider it to be social norms. It certainly isn't entitlement.
That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely.
Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.
Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.
Open source is like capitalism. But a project's success is measured in commitment instead of capital.
Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.
> 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.
Furthermore, if we're to interpret this clause as "do not place any trust in this software whatsoever" then I guess that's really bad news for the security community at large.
It's not really surprising that the Rust community is made out of people who've chosen to take extra effort in security, and that they wouldn't tolerate a cavalier attitude to it. It's disappointing that this was expressed in an unconstructive way.
I didn't see any discussion of legal liability, just a community deciding to stop using and supporting this library.
(Just going by Klabnik's article, I knew nothing about this library before reading it. There may be more context of which I'm not aware.)
This is a really bad answer because the most reliable and robust free software projects out there all use this same boilerplate license warnings. This is just for legal protection.
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 community ostracism/obnoxious messages to incentivise some degree of quality?
There is a difference between "Hey, this is a silly side project so definitely use at your own risk, as far as I'm concerned its a place for me to learn and should be treated as a toy" and "Hey, I think this is worth your time, you should use this in your production stack, and obviously I've set up legal protections so you can't sue me if something goes wrong, but I am trying to push this as something lots of people should use and trust".
If someone walks into my house and tries cookies I'm clearly learning how to make and then throws up, that's very different than me putting up a big "FREE AMAZING BETTER COOKIES" sign on the sidewalk and handing them out and having people throw up. In both scenarios, the cookies are free! What are you blaming me for! How entitled! In the first, I think that position is more defendable. In the second, ehhh.....
For the record -- I'm not super familiar with this project, but I think that a lot of people don't consider the ramifications of being successful sometimes: your project could be used by a big company and lead to people's information getting hacked (and those people had nothing to do with any of these decisions). The only thing asked is to be upfront that this is not intended for that, as opposed to the temptation of calling your thing the best and telling everyone to use it. In the run up of a project, I think it's easy to forget that and get really hyped on showing how your thing is better than some incumbent for example. Just something to keep in mind.
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).
EDIT: This rant is a general reply to your general sentiment, not a specific reply to this particular case. I have no idea whether the author did in fact signal appropriately their design, risk, etc.
It doesn't prevent us from saying "operating in this way is bad/destructive", even if one chooses not to use the code or service.
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.
This whole thing was a feedback circle of increasing hostility between the community/contributors and this developer. At some points the developer was very unresponsive, leading to disappointment from the community, but then some very uncalled for personal attacks came from the community. I think the developer received some justified criticism, but I still understand his perspective, putting work in and getting abuse back sucks.
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.
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).
I'd argue that forking and developing independently of the developer is as big of a middle finger as a developer taking their ball and going home. It just depends on who is on the receiving end.
I don't think either side is right here, but I don't think creating a public fork and building a community around that is an unbiased and neutral response either and should only be done in extreme circumstances... Which is does seem like what happened here.
(.Net is probably not unique in this regard, but it's what I'm familiar with.)
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.
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.
If he no longer wants to participate in the community, then deleting the repo was a good decision. It's not like the code is actually gone, other people have copies of it, and now that the original repo is gone nobody will mistakenly go to his repo and find it abandoned. It's basically the equivalent of boarding up the windows before you abandon a building.
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.
That is actually one of the things we teach the kids who are in these situations to do. It is ok to have a boundary, it is ok to leave the situation and it is ok to stand your ground. You don't ask for abuser validation nor permission.
Working in the context of Security does not grant you a blank check to be an asshole.
And what exactly are you contributing to this project author to match your demands of them immediately fixing flaws that are found?
I demand you go write a tool that lets me query projects and tells me if you think they are a toy or not. I'll wait.
If hope the plural we is also ready to monetarily compensate the developer for their time. Otherwise you don't have any basis for your expectation.
Deleted Comment
Or, assume all OSS projects are toy projects unless stated otherwise.
Usually the serious ones offer a support license for a fee, or are supported financially by companies. Otherwise, it's just someone building cool stuff for free.
Also, it's probably fair that most OSS maintainers aren't marketing their projects too aggressively outside of a blog post or a Reddit submission. When they take off, it's usually other developers hyping them and that hype usually comes from being lightweight, easy to configure or super fast. It's not until a project has been hyped by the community do people start trying to put it into production and looking into security issues.
Deleted Comment
It's "bear the brunt".
This article is someone who did that research on multiple Rust HTTP clients and reported what they found:
https://medium.com/@shnatsel/smoke-testing-rust-http-clients...
Which I believe is what kicked off the events leading to Klabnik's blog post?
Ok.
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.
- 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".
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.
We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.
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.
If people come to rely on your project, you are not more responsible.
I've been in the business since before open source was much of anything but a dream, and frankly, I wish a lot of more people would shutter their projects when/if they face these kinds of unreasonable expectations.
The vitriol and entitlement towards maintainers is sickening at times, and unless those affected close the doors, I'm afraid it'll continue to be ignored, and maintainers will continue to burn out.
Burn out is a real problem in the industry, and we really shouldn't help burn people out when it comes to work they do for free!
If there is one trend that has been consistent in the development world it has been that there are always people willing to keep iterating on libraries to get better and better implementations.