Announcement

Collapse
No announcement yet.

University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    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.
    You have to jump to a lot of crazy conclusions to believe this fits into Treason somehow. By the same logic speeding or shoplifting is treason too if done to "aid the enemy." So basically you've done a fantastic job of proving you can make anything be treason with enough mental gymnastics. I'm so glad you brought this up...

    Comment


    • #72
      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.
      Well, some people from UMN deliberately slipped some malicious code into the kernel. The fact that some of the code that was submitted by them during this research might have been legitimate could have been a part of the "scheme". Shortly after this came to light another UMN guy submitted a sketchy patch. It was not just GKH's opinion, everybody in that thread agreed that the code was wrong. Does it really matter if it introduced a bug or was just solving a non-existent problem?

      Comment


      • #73
        Originally posted by zexelon View Post
        The 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.
        You are raising a valid question about open source development. However, don't hold your breath waiting for quality coming out of closed source software. Everybody 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.

        Comment


        • #74
          Originally posted by oiaohm View Post
          https://www.workforce.com/news/sabot...-an-inside-job
          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.
          Thanks for sharing the link, quite an interesting quick read. You are definitely correct that the kernel does not need people explicitly screwing it up for research with no intent to control or retract when your research is done.

          Comment


          • #75
            Originally posted by obri View Post
            Why does the word "assholes" come to my mind?
            What have arseholes ever done to you to get put in the same group as these abusive researchers?

            Comment


            • #76
              Originally posted by martinus View Post
              Everybody 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.
              This is so true. It is naive to think that development behind closed doors is "perfection" just because you can't see it!

              Comment


              • #77
                Originally posted by gigi View Post
                in 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 Post
                Also 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?
                Man, 3 brand new accounts in a thread. That's pretty unusual in something that wouldn't start a flame war. It's a good thing they're all:
                • 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?

                Comment


                • #78
                  Those Chinese names sound to me like CCP stands behind it through their "Confucius institutes" that bring corruption to the universities worldwide.

                  Comment


                  • #79
                    Dear University of Minnesota,

                    Fuck off.

                    Kindly,

                    A Linux user

                    Comment


                    • #80
                      Originally posted by drjohnnyfever View Post
                      You have to jump to a lot of crazy conclusions to believe this fits into Treason somehow. By the same logic speeding or shoplifting is treason too if done to "aid the enemy." So basically you've done a fantastic job of proving you can make anything be treason with enough mental gymnastics. I'm so glad you brought this up...
                      One of the USA world war II cases that the Treason change stuck was basically shoplifting so no my logic is not drawn too far there is not a case for speeding but there is a case for reckless driving as well in the world war II cases for a person prosecuted for Treason that person got off so speeding might be ok. The USA treason law when its been enforced was mega exploited and the law has never been fixed to correct those faults because the USA Treason Law went out of usage due to there not been a clear define enemy past the end of World War II for the USA.

                      Leaving badly written laws on the book just because no one is currently using them can come back bite in future.

                      Sorry I have not jumped to crazy conclusions its just how bad the USA Treason Law is in fact written and has historically been used. Please note the USA Treason law does not even say it has to be intentionally ading the enemy so ading the enemy by delieving a random person mail as a mail worker who happens to be enemy of state under how flaws the USA law the mail person could be prosecuted.

                      At least places like China have functionally sane Treason laws where the actions have to be intentional.

                      https://www.law.cornell.edu/uscode/text/18/2381
                      giving them aid and comfort within the United States or elsewhere

                      drjohnnyfever for something that can result in the death penalty you want way better written then above as the only condition required to prosecute. Like the word intentionally would good addition there.

                      adheres to their enemies
                      This one has been taken to insane in one of the world war II cases where a person was a prisoner on enemy battleship who got prosecuted for Treason successfully.

                      The treason law has been sitting on the USA books but the cases from World War II basically extended what could be prosecuted into the mega insane. Just no one has been using the charge recently and maybe if someone had been the law would have been updated by now to add a few extra words to prevent incorrect usage.

                      Sections almost every countries law books are broken to the insane normally in laws that are not being used a the moment does not mean we should ignore their existence and fail to notice how faulty they are. Problem here its really simple to think that it would take jumping to crazy conclusions while forgetting courts can be really good at doing just that.

                      Comment

                      Working...
                      X