I’m starting to really wish reddit wasn’t the default community forum for everything.
A Sad Day for Rust
431–440 of 1001 posts
Re: A Sad Day for Rust
#432What is the issue here actually?
Fork the project and un-unsafe it.
Re: A Sad Day for Rust
#433I 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…
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.
Re: A Sad Day for Rust
#434If your language promises some kind of new feature (e.g. "safety") but offers a back door you could drive a truck through (e.g. 'unsafe'), then ensuring that back door is used appropriately and in good taste comes down to culture policing , which, as we've learned in other areas, is something the internet does not handle well. As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, i…
I would prefer to see a positive badge for "this project doesn't directly use unsafe" or similar, which maintainers can choose to put in their README in the same way that they currently put build-status, test-status and other badges. The actual badge state is produced by tooling (a CI system) so it stays up to date and you can follow a link to a (tooling generated) report with more info, so it's relatively easy to verify.
Maintainers that don't care don't have to use the badge (even if their project does in fact avoid unsafe), but the choice to include the badge acts as an implicit signal of intent. When I see a crate with green CI status badges (or in this case a green safety badge) that's a signal I can use to help judge whether I want to depend on the crate.
No one needs to be flagged or called out if they're not interested in that aspect of maintainership.
I think the hard part is that actual quality is a spectrum and no-unsafe-at-all isn't necessarily the best goal for many crates. So ideally the badge would show some more granular safety score. But scoring effectively is difficult, and the so is correctly interpreting a heuristic score.
Re: A Sad Day for Rust
#435Earlier quoted context omitted.
Ada’s language is probably clearer and less loaded: checked and unchecked.
Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names. The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)
I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.
Re: A Sad Day for Rust
#436I 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…
[deleted]
Re: A Sad Day for Rust
#437Earlier quoted context omitted.
As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.
Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking a…
The level of entitlement here is absolutely insane.
If the community cares about security then should this happen:
> Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.
The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."
Re: A Sad Day for Rust
#438I think Github (and other services that host OS software) needs something like "thank you box", that's just alongside Issues. Even if I am not able to contribute to some project I use and like (mostly because I don't have enough technical knowledge yet) very often I would like to - at least - say how much grateful I am for what this person is doing. There is some need for positive energy or gratitude, as we - who are happy - won't usually post an Issue saying that we are happy, everything is working fine. It seems then that there are only issues, and people who are angry or unhappy seem to be the loudest.
How else, we who are grateful but silent users - can help maintainers and contributor to know that there is large or even larger amount of people who are happy and even amazed by their work?
Re: A Sad Day for Rust
#439A 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…
Agreed 100%. May I add one point?
The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines.
I feel many people get toxic if they had unrealistic expectations -- and that's of course not okay.
But IMO the OSS maintainers can be a little more preliminarily proactive in managing expectations from earlier stages.
Re: A Sad Day for Rust
#440Earlier quoted context omitted.
If I understand correctly, your anecdotal evidence is what makes this not "armchair psychology"?
What's wrong with simply sharing personal observations based on the decades of related personal experience? Anyone who has some training in science has learned to always be looking for patterns.
Well for one thing it would make me able to go around claiming that generally black people are criminals and rapists and that it continues to be so because the young here in my city are being sucked in to the "monkey see, monkey do" phenomenon because they have low emotional intelligence and distrust authority, blah blah. That is based on the past decade of my life and the observations I've made and the experiences I've had.
I of course don't go around claiming such because it's nonsense and stupid.