>>3776
Those in charge of merge requests also approved it, despite the submission having a massive security flaw while only claiming to fix some typos, and banned the entire university email domain from submitting requests, when all of the malicious submissions from the University were apparently all from Gmail accounts, that I assume were handmade for this test; turning a massive repository into an imprompptu guinea pig was a shameful idea, but it reveals a major weakness in open-source development; for whatever reason (that I have suspicions for that I won't go into detail because it's almost irrelevant; no, I'm not alledging that it was sabotage, though it's not an impossible option; it's simply not what I'm thinking of at this moment), some people don't check enough to see if the things they download haven't tampered with, aside from not going to incredibly obvious websites filled with malware. Some even insist that open-source software is inherently safe, which is ill-advise and encourages the sort of mental laziness that got modern software into the mess it's in today; open-source software is only more likely to get fixed faster if security is compromised because anyone with the knowledge can fix it and submit a pull request (which does not necessarily mean it will be merged into the master branch). Here are at least two reasons why this is
not the same as "open-source software is inherently safe":
>you need to recompile the program or download the new latest binary of the program in order to have said patch apply to your version in the first place
>as I alluded to before, a pull request may not get immediately accepted, or even accepted at all, for a myriad of reasons
There's also the fact that fixing a problem is not the same as not having a problem at all, it just means the problem is less able to be a problem. But because some people don't do this, they don't actually take the time to understand what the code for the program they want to use actually does, let alone use any hash verification methods that the owner of the repository may have given the users as an option to verify if the binary is the one that the owner of the repository attempted to serve to the users.
The lesson to take from this is to pay attention to merge requests. Understand the languages of the programs that you're using, pay attention to the pull requests and what they actually change, and if you download binaries, at least verify the hashes so that you're at least more sure that it's the intended one and not some malicious executable that was able to pass itself off as the real thing because you either didn't know how to verify, or you did, but you didn't do so this time and you're about to regret it.
Also, banning the entire domain probably earned them some bad blood between them and some members of the university (and maybe even outside the university); again, none of the university's email addresses were submitting the malicious pull requests, so they may have angered an undetermined amount of people for an action that won't actually defend the project against malicious pull requests, or even punish those who submitted said pull requests.
>>3762
As
>>3763 said, they did and that's the problem; they target on the entire university's domain when the malicious code was apparently submitted by pull requests by Gmail accounts; they not only were neglectful about checking what the submission actually did, they also did an incredibly bad job at punishing the university; if they ever wanted to do it again, nothing about them banning the university's domain will stop them, as they almost never used them back in this incident (there was apparently one, but it quite literally did nothing).