Thats like “child labor is bad because they cant do high quality work”.
Bullying is bad. Period.
Closed source projects are also subject to bullying.
Project managers pressuring developers to implement half assed features in an afternoon because sales sold a feature that doesn’t exist and have signed a deal to have it delivered tomorrow morning. Who has time to review the code and ensure there are no SQL injection vulnerabilities? Just push it!
Three years ago, #FDroid had a similar kind of attempt as the #xz #backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn’t found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection #vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now
https://social.librem.one/@eighthave/112194828562355097
Steiner wrote this week that the original coder deleted their account as soon as F-Droid’s maintainers attempted to review the code, and that he thinks that the user’s behavior, as well as “all the attention from random new accounts” has led him to believe “it could be a deliberate attempt to insert the vuln.”
This is pretty significant: the first documented case of these tactics being used to insert a vulnerability, apart from xz. So probably the same actors have been trying this on multiple projects.
I hope other maintainers who have experienced similar pressure tactics will come forward, even if they’re not aware of any backdoors. For any project where this has taken place and the code was merged, the code and commit history needs to be audited.
Im a former contributor to F-Droid with various merged pull requests. Looking at the indicated pull request I really doubt that it was an intentional attack. First of all its easy to forget for a new developer to escape SQL parameters, and the docs dont even mention a risk of SQL injection attacks. And of the users pushing for the PR to be merged, one is a long-time F-Droid contributor, and the other also looks like a real human with many contributions in other repos, so no sockpuppets in sight.
It simply looks like standard open source behaviour, for better or for worse. A new user makes a contribution for a highly demanded feature, and users want it to get merged as soon as possible. Maintainers are discussing the big picture of the change and want to avoid breaking changes, without getting into code review yet. The new contributor seems unwilling to make any design changes to his PR, and gets frustrated that it doesnt get merged as is. The potential vulnerability is only noticed half a year after the PR was opened, at which point it was already de facto abandoned. So not an attack, but simply a developer who is new to open source and doesnt understand how the process works.
