Announcement

Collapse
No announcement yet.

University of Minnesota Linux "Hypocrite Commit" Researchers Publish Open Letter

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

  • This Burn Loot Murder University terrorism issue was just covered on gamers nexus.

    Comment


    • Originally posted by ultimA View Post

      This group has knowingly and on purpose introduced bugs and vulnerabilities into a piece of software that millions of people around the globe rely on, many of them in mission-critical environments, and they admittedly didn't even feel bad about it, they openly said they see nothing wrong with their methodology.
      Good this is not what happened!

      Comment


      • Originally posted by codewiz View Post
        Greg K-H's response is quite unforgiving:



        https://lore.kernel.org/lkml/[email protected]/
        Which begs the question... What's gonna happen next time he reviews and accepts (or submit) a buggy patch? However unintentional it was, it looks like most people both working in the kernel and here say it's a non-problem that definitely does not need to be studied. So should I say "too bad that used-after-free bug was introduced more than 5 years ago, really nothing we can do"...

        I don't know, I personally think it's better, once, to slap a child who does not behave instead of letting them getting driven over by a car because once again they were not listening. Sure, a slap might be too strong, there are certainly other ways, but given the 2, I'd prefer my child to be unhappy for 5 minutes and live a long life instead of dying there. As much as I understand all the discussion about a slap being unnecessary or a bad way of doing it, when the child gets driven over, I find normal to ask parents what the heck they were thinking. There are enough CVEs (and obvious regressions) to say the kernel does not "behave".

        Comment


        • Originally posted by ultimA View Post

          This has nothing to do with cancel culture. This group has knowingly and on purpose introduced bugs and vulnerabilities into a piece of software that millions of people around the globe rely on, many of them in mission-critical environments, and they admittedly didn't even feel bad about it, they openly said they see nothing wrong with their methodology. They only sent out their open-letter when they got banned as a result, which in light of their previous statements just days ago, is clearly not honest. This is justified self-defense from the kernel developers. Claiming this is cancel culture is like saying it is cancel culture to ban somebody from your home after they've committed vandalism in it and they don't even see what they did wrong and they'd do it again.
          Why feed the troll? They made something stupid and damaged Linux project.

          Let Linux Foundation get damage control and compensation for such awful actions.

          Throw money? A consulting firm to audit the code? Whatever, they deserve to compensate more than what they did as a pragmatic "sorry" to the community. Words are nothing, actions are the important stuff.

          Linux kernel is a giant project that is very interesting for students to acquire experience and for researchers too.

          Of course, new procedures and tools should be made to avoid this kind of disasters. But they choose the very wrong way of do things and ought to pay for it.

          If real world was better, they should already be in a trial and a strong resolution done in less than a week. But well see.

          Comment


          • Originally posted by User42 View Post

            Good this is not what happened!
            Of course this is what happened. First, it is undeniable they tried to introduced bugs to the kernel. They have an earlier paper about it here, so I guess you won't dispute that. Second, when confronted, first they denied they did any such thing and still tried to get a new nonsense patch in. Then, when the issue was brought into a more public light, they openly defended themselves claiming they though it was okay what they did because it is not human research.

            They said, and I'm quoting from the researcher's own public FAQ about the case:
            "This is not considered human research. We send the emails to the Linux community and seek community feedback. The study does not blame any maintainers but reveals issues in the process. ... Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned - Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form."

            Now, obviously there are a couple of problems with the above quote:
            1) They base "good" and "bad" entirely on the fact whether it is considered human research by *others*.
            2) It doesn't actually address their own judgement or admit they were wrong. They only admit they should have asked somebody earlier.
            3) They ignore that when the IRB (Institutional Review Board) gave them green light mid-research, they still thought it was okay and continued with it.
            4) Beside the question whether this was human research or not, they completely ignore that their methodology was unethical for other reasons too.

            Basically, their FAQ is just like their research. They ask the wrong questions, reach the wrong conclusions, and fail to discuss the actual problems. All the while trying to submit new fake patches, even after they were found out, LOL. So, User42, care to elaborate where I was wrong?
            Last edited by ultimA; 26 April 2021, 11:09 AM.

            Comment


            • Originally posted by cynical View Post
              This letter is obviously fake. If you don’t have the common sense to realize that surreptitiously submitting bugs for inclusion into the Linux kernel was a bad thing, then certainly you don’t have the capacity to feel sorry for doing it.

              This is clearly a last ditch attempt to prevent the ban and patch reversion from taking place. All patches from them should be pulled. If there are real bugs, then investigate them and write new patches. This group is not trustworthy.
              Well I can't say you're not living up to your name. I guess it is best to err on the side of caution.

              Comment


              • Originally posted by BesiegedAce View Post
                Well I can't say you're not living up to your name. I guess it is best to err on the side of caution.

                Particularly once you start considering where the Linux kernel end up.

                There is a miss belief that the open source communities are this we welcome everyone place. The hard reality is they are not there is a requirement to maintain trust and trust is really simple to lose with extrema effects to that loss. Yes they appear friendly until you are not trustworthy then you have pitchfork problem that will not back off simply.

                Comment


                • The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it. If the researchers had not said anything no-one would have ever known.

                  Makes you wonder how many backdoors and bugs have been purposely added to various open source projects by supposedly trusted contributors.

                  Comment


                  • Originally posted by sophisticles View Post
                    The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it. If the researchers had not said anything no-one would have ever known.

                    Makes you wonder how many backdoors and bugs have been purposely added to various open source projects by supposedly trusted contributors.
                    No the reason why they got caught second time was the many eyes things. Of course there is the knowledge side to the many eyes on how well it works.

                    The research paper changed something that would be ignored as a common human error and not tracked to be taken as a serous problem to be tracked in case of repeating behaviour.

                    That the thing with git blame and other features found in modern day source management you can track to exactly who was the developer who introduced the bug. You see contributors cease to be trusted at different times because down the road those questionable patches they have been getting in have been recognised for what they are.

                    Its very much a false idea that no one would have ever known.

                    Many eyes thing is true over the long term due to the detail histories good source management tools keep and how those can be processed seeing what developers are the source of different security faults. Short term not as good.

                    Yes you can with the source histories see what developers are introducing what types of bugs. History is the big thing here if you don't learn from history you are doomed to repeat it. This is part of the open source world a flaw happens then items are put in place to detect this kind of problem.

                    ** We will update this article with additional information as it becomes available. We have also published a playbook to guide any security team that has SolarWinds in their environment and is look…

                    sophisticles being closed source does it make it immune to the supposedly trusted contributor problem or third party hack in problems. Closed source does remove the many eyes thing.

                    Its not just the Linux kernel where we have seen the many eyes thing work. So basically those are two supply chain attacks the php open source one gets detected because of many eyes that open source has allowed and the solarwinds one is closed source and was missed. There is a trend that a supply chain attack is more likely to be detected in open source than closed source all due to the number of people who can look at the source.

                    This does not make the many eyes system 100 percent perfect. But there are enough supply chain attacks documented to say that many eyes reviewing is a mitigation factor.

                    Software development is a hostile world be it closed or open source.

                    Originally posted by sophisticles View Post
                    The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it.
                    This idea is not really based on broad research. This is you taking a jump of a cliff because this one paper matches you personal bias the broad research going back centuries disagrees with your idea that its stupid. The data on different supply chain attacks of the centuries say that many eyes reviewing security reduce supply chain attacks is better than limited individuals this is not restricted to source code/software development. So many eyes reviewing does make open source generally more secure than closed source for the same reasons why a many eyes review of a ports warehouse results in better security of the warehouse than a individual because the many eyes will look at the problem differently considering more possible issues so come up with better solutions and countermeasures.

                    The less diverse you solution review system is the more likely it will be defective. Remember the many eyes thing does also apply to how we calculate sample sizes for medical trials and the like to make sure there is enough exposure.

                    Please note I said generally more secure not absolutely secure. Many eyes is not a magic bullet that fixes everything but a factor that has to be considered.

                    The hard point with security is that is more often than not a probability not a hard black or white answer.

                    The large sample size data on many eyes always says its better security by probability. But there is always outlier risk like the table vs cash-register as a store owner where should you place your money. Yes there the highest probability says the cash register is the safer than the table for the money but the outlier event the criminal run in grabs the cash register and leaves the stack of money that was sitting on the table. Sophisticles the reality is the way you said many eyes is stupid would be saying that business should not put money in cash registers but leave it on the table because of the outlier risk of the thief steeling the cash register.

                    Comment


                    • Originally posted by sophisticles View Post
                      The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it.
                      Except not entirely, because they didn't go through the full process to get the change merged in.

                      More importantly, they were use-after-free bugs, rather than backdoors. Still bad, but as we all know that bugs sometimes creep into the kernel, it's not surprising that someone deliberately trying to hide them is able to do so.

                      They explain this in their paper, which I checked specifically to see how far the faithless patches actually got.

                      Comment

                      Working...
                      X