In some open source projects there is a lot of leeching and little contributions.
In 2020 the sole developer of Invidious stepped away from development because of burn out. https://omar.yt/posts/stepping-away-from-open-source
Also in 2020 developer Raymond Hill archived the uMatrix browser add-on https://news.ycombinator.com/item?id=24532973
I will never hand over development to whoever, I had my lesson in the past -- I wouldn't like that someone would turn the project into something I never intended it to become (monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork under a new name. For now I resisted doing this, so people will have to be patient for new stable release.
What would actually help is that people help to completely investigate existing issues instead of keep asking me to add yet more features. Turns out people willing to step in the code to investigate and pinpoint exactly where is an issue (or that there is no issue) is incredibly rare.
More people need to operate like Linus Torvalds. Call people on their shit. Respectfully of course.
I've always been a fan of "pull requests welcome" when someone asks me for something.
The problem is when people then open huge PRs and expect you to take time to review them, then eventually merge them.
Especially when it's something you don't want in your codebase because it introduce a big unnecessary "refactoring" or a feature that you don't want to have to maintain forever.
I can’t imagine just opening a giant PR without having extensive contact and coordination with the maintainer. Almost any amount of incremental safe steps would be preferable to a giant PR, even with extensive communication. I once introduced fully strict typescript into a vanilla js codebase and it took dozens of small PRs to do so. It was made more complicated by the fact that it was a library, but still. The communication made the entire process smooth and let everyone be confident the changes were correct along the way. If I’d done it all at once without any coordination, it would have been faster for me, but at the cost of the maintainer’s sanity and time.
The point is that saying "pull requests welcome" is still work for the maintainer, because now you have to have these discussions with potential contributors, sometimes explain them why you don't want to maintain the feature, or explain them why this PR is not the way you want...
So either way it's work, it's important to keep in mind before saying "just send a PR".
as a non developer myself, to my understanding, the vulnerabilities were implemented in test binaries?
If so, i question why those were shipped to the client. Unless they were built into the package itself on the mirror, in which case, still curious as to why that would be. I would think tests are entirely benign and do nothing. Seems like it would be incredibly bad practice to do otherwise?
Seems like an obvious vector to shutdown any potential fuckery. But what do i fucking know.
It's common to bundle test artefacts with the release tarballs. The reason is that when Linux distributions build the software from the tarballs, they often run the tests to ensure that they pass.
