Announcement
Collapse
No announcement yet.
University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs
Collapse
X
-
Those Chinese names sound to me like CCP stands behind it through their "Confucius institutes" that bring corruption to the universities worldwide.
-
Originally posted by gigi View Postin the name of research, person has introduced or frankly verified that malicious commits can be indeed introduced without much hassle in open source projects (i mean where source code is available without any restrictions to view and with dedication resolve issues). i wonder how open source community will react to 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021.Originally posted by lkucharczyk View PostAlso from the paper:A. Ethical Considerations
Ensuring the safety of the experiment. In the experiment,we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code.
Seems like they failed, no?Originally posted by User42 View Post
By all mean, read!
https://github.com/QiushiWu/QiushiWu...Insecurity.pdf
What you say makes sense and is even quantified with latency period, catch rate, etc. Look at figure 1... Use after free bug, 42% chance of being spotted during review. Would stay unfixed in the kernel 5 years on average. Wouldn't it be great to increase the likelihood of that thing being spotted on day 1 hopefully or at least within months, not years after release? If you don't know where the problem is, how prevalent it is, how it gets through review and what impact it has on the code, how can you "fix" it in general?- promoting sites and future events related to the study's authors
- minimizing the negative impact of this study and otherwise gaslighting concerns about it
- promoting the "need" for studies like this
- specifically interested and/or knowledgeable about this topic
I mean, without them, I probably wouldn't have known about the importance of auditing open source code, right? Or even how to view the study's authors and the related organizations. Astroturfing is super important. I mean, it's not like grass can grow on its own, right? Why, I might even hire them to review my open-source project, which is probably super insecure without their expertise.
/s
In all seriousness, maybe try open and direct engagement next time? It's a small relatively field and the linux fanbase has a high occurrence of paranoia. Which makes me a bit of a dick, I guess, for pointing this out with the knowledge that it's going to set some tinfoil hats spinning. But, with two mistakes about not communicating properly in a row, maybe the third time it'll sink in?
- Likes 8
Leave a comment:
-
Originally posted by martinus View PostEverybody who works inside a corporation knows how the power structure and recognition systems inside a corporation will automatically lead to the low level of quality and secureness that closed source software is measurably known for.
- Likes 4
Leave a comment:
-
Originally posted by oiaohm View PostThe latest news and commentary on workplace and employment. Find free resources on labor insights, working conditions, and people management software labor efficiency and helping your teams achieve success.
What you have stated here is a false idea. In closed source you can still have your sabotaging parties that can be very hard to find.
Leave a comment:
-
Originally posted by zexelon View PostThe question is how do you validate contributor's trustworthiness in a community that champions total freedom of contribution? In closed source everyone contributing can be 100% managed and vetted.
- Likes 3
Leave a comment:
-
Originally posted by User42 View Post
This is not about banning people because those commits were potentially harmful. I hope it is clear if that was the reason, everybody would be banned: introducing new bugs is a very common thing after all. If you look at the series of emails, Greg most likely did not like being treated as a lab rat (understandable) especially without anybody in the kernel being involved (very understandable). Though a certain amount of secrecy is necessary not to bias the study, not involving anyone is a bad idea.
Now there is a new series of patches that he perceived as useless, not harmful, useless. It looks like his conclusion was that they are being used as lab rats again, therefore ban. Now, as Sonadow noted, some reviewer actually think some of these patches are good, fix problems and are probably not malicious. Considering the content of the paper, this might be (I insist, might be) the result of the application of the workflow they recommended or it might be a new experiment. Anyway he was not afraid of harmful commits, he clearly does not want the kernel to become an Academic playground.
- Likes 1
Leave a comment:
-
Originally posted by oiaohm View Post
No the conditional requirements. "depending on the results of the sabotage." key and "giving aid to a enemy" Word War II the enemy was clearly defined so Treason charges are more possible. The law is still on the books for Treason in the USA but its hard prosecute due to the requirements current day and since world war II. Sabotage is a lot more simple. The china version of Treason allows for Sabotage of government properly to be prosecuted without confirming enemy because you doing the sabotage was the enemy.
Reason for the lack of recent historic examples treason examples in USA is lack of clear define enemy. Something to remember a code modification might sit in place with a flaw for a decade+ before being found by then the USA could be at war with a party that is a clear define enemy and could be in the mood again to use the Treason change. Remember the Linux kernel has kept detail records of who submitted what. So being noticed and removed is technically saving their hide against future risk.
Leave a comment:
-
Originally posted by drjohnnyfever View PostThe last time someone was convicted of Treason in the United States was 1952 over events that happened in World War II, and eventually the sentence was commuted. If your interpretations of Treason law were at all reasonable one would expect there to be a at least a single historical example.
Reason for the lack of recent historic examples treason examples in USA is lack of clear define enemy. Something to remember a code modification might sit in place with a flaw for a decade+ before being found by then the USA could be at war with a party that is a clear define enemy and could be in the mood again to use the Treason change. Remember the Linux kernel has kept detail records of who submitted what. So being noticed and removed is technically saving their hide against future risk.
- Likes 1
Leave a comment:
Leave a comment: