Some of us in the Rust community wrote a letter of support for the actix maintainer. In case anyone else thinks what happened sucks and wanted to show support.
A Sad Day for Rust
791–800 of 1001 posts
Re: A Sad Day for Rust
#792Earlier quoted context omitted.
Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: 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 w…
> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)
I don't think this is true. In fact, today, I privately forked one of the aforementioned libraries (httparse) and removed all of the unsafe parts in under an hour (without introducing any new memory allocations, I might add). All the tests pass.
It's not insurmountable. It just takes a little bit of elbow grease and self-discipline ;)
Re: A Sad Day for Rust
#793This 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 h…
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.
Re: A Sad Day for Rust
#794Earlier quoted context omitted.
Of course they don't. It is Free OSS. And you implying that the maintainer put someone's life in harms way is simply not true. And the LICENSE says - no warranty or guarantee whatsoever... Use at your one risk. And the homeless people analogy makes very little sense, excuse me for being blunt. You are comparing software developers who use FOSS to homeless people??? You are comparing someone's FOSS project on github t…
> And the LICENSE says - no warranty or guarantee whatsoever Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.
You keep using bizarre analogies and terminology. Homeless people, poisoning food, arrested... It is as sounds as saying a dragon gorilla group consumes errors in the background...
Re: A Sad Day for Rust
#795Earlier quoted context omitted.
> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. `unsafe` is a PL term that refers to _soundness_. In Rust, an `unsafe { ... }` block is required to perform an `unsafe` operation, and it precisely means "The code in this block has been proven _sound_". If the code in the block turns out to be _unsound_, e.g., because the proof is incorrect, or non-existent, then the…
That's an interesting way too look at it. But that's not how it works in practice. Almost no one in industry is going to write proofs for their unsafe code. It didn't happen for C or C++ and it won't happen for Rust.
In Rust you at least know where to look at, whereas in C/C++ all code can be "unsafe". With that said, writing unsafe Rust is much easier to screw up than C/C++, since you have to uphold more invariants in unsafe Rust than in C to avoid UB (like never having two mutable references to the same thing at the same time. The very issue which was raised in the actix repository)
Re: A Sad Day for Rust
#796Steve, you have done a fantastic job. Don't let these issues get you down. As an indication of that, I've been implementing an ownership/borrowing system for D. I expect to see some of the same issues you brought up. But for the people that want to use it correctly, it will produce the benefits. And that's what I care about.
Thanks Walter. I've been following along with your work, actually, though I don't know enough D these days to really understand it fully. Neat to see though!
Re: A Sad Day for Rust
#797Earlier quoted context omitted.
Notice how every single line in your comment starts with "I". You alone decided that maintainers have all these obligations (which I would consider reasonable things to do for the record), but the maintainer of this library doesn't agree, and the license doesn't require it, so you're just setting yourself up for disappointment here.
It seems much of the disagreement may stem from lack of consensus around the semantics of: 'responsibility' 'requirement' 'obligation' 'should' 'can' I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do…
> I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).
I agree with all of this, but I also feel that you need to be mentally prepared for any maintainer to fail to meet these moral responsibilities unless you want to be disappointed and should act accordingly (not saying you don't already do this in practice).
> I accept that it's not a consensus. I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.
I agree 100%.
Re: A Sad Day for Rust
#798A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…
> 2. Open source participants are volunteers and owe you nothing.
If this were true in the strictest sense, then they would be free to put malicious code and trick you into using their stack just to then steal credit card numbers from your database. Of course this is not true, and they would appear to at the every least owe us "good faith" or perhaps some basic guarantee that they are not purposefully trying to criminally attack you. This may seem like a useless edge case to bring up, except for the fact that the law does have some amount of consideration for negligence.
Arbitrary people you don't know owe you nothing too, and yet if you walk onto their premises and get hurt, the law has found in certain circumstances that they are indeed at fault. Expectations and responsibilities evolve with time, and as new scenarios come up. It is not clear to me that putting up a project that invites people to use it in production could not be argued to some extent to be negligent if it willfully blocks and delays fixes that could affect real world customers.
At the end of the day, if people were using my code in production, and a discovered exploit was used to steal people's data and I could have prevented this by merging in code that wasn't 100% to my aesthetic liking, then I think I would feel bad. Fault isn't binary, maybe its the fault of a random company using my framework for not being up to the minute on all vulnerabilities and manually patching the code themselves, maybe its their fault for using my framework in the first place given the youth of the project too. But I don't think I would go to sleep that night feeling great is all I'm saying.
I'm not super familiar with this particular case, but the OP blog post was phrased as kind of wanting to open up a dialog or discussion on the nature of these issues. I am bringing up some thoughts about this stuff I've had for a while and I think at least help to understand some of the moving parts involved. For the record, I don't really know where I stand "absolutely", or if its possible to have a clear principle that doesn't take into account some number of additional variables (how the project was portrayed, how many users it has, etc.).
Re: A Sad Day for Rust
#799Earlier quoted context omitted.
That is a false equivalence, roller coasters have far more material risk given human lives are at stake.
If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers? Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.
Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?
Re: A Sad Day for Rust
#800Earlier quoted context omitted.
It is enough, and I don't disagree with "the notion of someone publishing their work under a free software or open source license being useful for the world." I have simply no idea where you got the idea that I would disagree with that. What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are gett…
> I have simply no idea where you got the idea that I would disagree with that. "If that's the case, then why open source it at all?" This is the part which made me feel you disagreed with it. However, may I ask if it is your belief something released under an open source license comes with an intent to maintain it (for others)? Or that releasing something under an open source license is a declaration of being a main…
>> "If that's the case, then why open source it at all"
> This is the part which made me feel you disagreed with it.
I am aware, and as I already explained, this is a rhetorical device which you mistook for my own personal belief. Obviously I don't believe OSS is bad. It's friggen great.
And that's a fair question. I am absolutely not saying that open source means you must maintain it. I am simply saying if you call yourself a maintainer then you are responsible for maintaining. If you don't want to maintain OSS, then don't. Just don't pretend you're a maintainer and that you have no responsibility to maintain. At best, pass it on to someone willing to maintain it. At worst, pretend you're working on it. As I said in my original comment, others should fork as needed.
And to add, I don't believe the original subject of the article, the now former maintainer of actix-web, did the wrong thing. I am in agreement with their decision to drop out. No one should be held to an unrealistic standard by entitled users and expected to put up with that BS. The part of my original comment that everyone has a problem with is seriously the least consequential phrase. Blows my mind that everyone is hyper focused on taking it out of context as well.