13 ms·

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel

• henearkr 5y ago
  Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.] They are conducting research to demonstrate that it is easy to introduce bugs in open source... (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) [removed this ranting that does not apply since they are contributing a lot to the kernel in good ways too]
  • throwaway823882 5y ago
    > the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards That's not true at all. There are many internet-critical projects with tons of holes that are not found for decades, because nobody except the core team ever looks at the code. You have to actually write tests, do fuzzing, static/memory analysis, etc to find bugs/security holes. Most open source projects don't even have tests. Assuming people are always looking for bugs in FOSS projects is like assuming people are always looking for code violations in skyscrapers, just because a lot of people walk around them.
  • gspr 5y ago
    > It's likely a university with professors that hate open source. This is a ridiculous conclusion. I do agree with the kernel maintainers here, but there is no way to conclude that the researchers in question "hate open source", and certainly not that such an attitude is shared by the university at large.
    • henearkr 5y ago
      [Edit: they seem to truly love OSS. See child comments. Sorry for my erroneous judgement. It reminded too much of anti-opensource FUD, I'm probably having PTSD of that time...] I fixed my sentence. I still think that these professors, either genuinely or by lack of willingness, do not understand the mechanism by which free software warrants its greater quality compared to proprietary ones (which is a fact). They just remind me the good old days of FUD against open source by Microsoft and its minions...
      • meepmorp 5y ago
        What papers or statements has this professor made to support that kind of allegation? Can you provide some links or references, please?
        • henearkr 5y ago
          I don't have the name of the professor. [Edited: it seems like they do love OSS and contribute a lot. See child comments.] I had based my consideration on the way they are testing the open-source development model. These professors actually love OSS... but they need to respect kernel maintainers request to stop these "experiments".
          • Pyramus 5y ago
            From the researchers: > In the past several years, we devote most of our time to improving the Linux kernel, and we have found and fixed more than one thousand kernel bugs; the extensive bug finding and fixing experience also allowed us to observe issues with the patching process and motivated us to improve it. Thus, we consider ourselves security researchers as well as OSS contributors. We respect OSS volunteers and honor their efforts. https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... It feels to me you have jumped to an untenable conclusion without even considering their point of view.
  • rusticpenn 5y ago
    At least in the university where I did my studies, each professor had their own way of thinking and you could not group them into any one basket.
    • henearkr 5y ago
      Fair point. I'll just leave my comment as it is. The university administration still bears responsibility in the fact that they waived the IRB.
      • tehwebguy 5y ago
        From the link, not sure if accurate: > Those commits are part of the following research: > https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap... > They introduce kernel bugs on purpose. Yesterday, I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes".
        • dash2 5y ago
          Interestingly, that paper states that they introduced 3 patches with bugs, but after acceptance, they immediately notified the maintainers and replaced the patches with correct, bug-free ones. So they claim the bugs never hit any git tree. They also state that their research had passed the university IRB. I don't know if that research relates to what they are doing now, though.
  • AnIdiotOnTheNet 5y ago
    > (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) Which is why there have never been multi-year critical security vulnerabilities in FOSS software.... right? Sarcasm aside, because of how FOSS software is packaged on Linux we've seen critical security bugs introduced by package maintainers into software that didn't have them!
    • henearkr 5y ago
      You need to compare what happens with vulnerabilities in OSS vs in proprietary. A maintainer pakage is just one more open source software (thus also in need of reviews and audits)... which is why some people prefer upstream-source-based distribs, such as Gentoo, Arch when you use git-based AUR packages, or LFS for the hardcore fans.
      • acdha 5y ago
        > You need to compare what happens with vulnerabilities in OSS vs in proprietary. Yes, you do need to make that comparison. Taking it as a given without analysis is the same as trusting the proprietary software vendors who claim to have robust QA on everything. Security is hard work and different from normal review. The number of people who hypothetically could do it is much greater than the number who actually do, especially if there isn’t an active effort to support that type of analysis. I’m not a huge fan of this professor’s research tactic but I would ask what the odds are that, say, an intelligence agency isn’t doing the same thing but with better concealment. Thinking about how to catch that without shutting down open-source contributions seems like an important problem.
  • TeMPOraL 5y ago
    > Not a big loss: these professors likely hate open source. > They are conducting research to demonstrate that it is easy to introduce bugs in open source... That's a very dangerous thought pattern. "They try to find flaws in a thing I find precious, therefore they must hate that thing." No, they may just as well be trying to identify flaws to make them visible and therefore easier to fix. Sunlight being the best disinfectant, and all that. (Conversely, people trying to destroy open source would not publicly identify themselves as researchers and reveal what they're doing.) > whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards How do we know that? We know things by regularly testing them. That's literally what this research is - checking how likely it is that intentional vulnerabilities are caught during review process.
    • henearkr 5y ago
      Auditability is at the core of its advantage over closed development. Submitting bugs is not really testing auditability, which happens over a longer timeframe and involves an order of magnitude more eyeballs. To adress your first critic: benevolence, and assuming everyone wants the best for the project, is very important in these models, because the resources are limited and dependent on enthusiasm. Blacklisting bad actors (even if they have "good reasons" to be bad) is very well justified.
      • idiotsecant 5y ago
        If the model assumes benevolence how can it possibly be viable long-term?
        • henearkr 5y ago
          Like that: malevolent actors are banned as soon as detected.
          • idiotsecant 5y ago
            What do you suppose is the ratio of undetected bad actors / detected bad actors? If it is anything other than zero I think the original point holds.
• bionhoward 5y ago
  seems extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...
  • hn8788 5y ago
    The university reviewed the "study" and said it was acceptable. From the email chain, it looks like they've already complained to the university multiple times, and have apparently been ignored. Banning anyone at the university from contributing seems like the only way to handle it since they can't trust the institution to ensure its students are doing unethical experiments.
    • rob74 5y ago
      Plus, it sets a precedent: if your university condones this kind of "research", you will have to face the consequences too...
  • deleted 5y ago
    [deleted]
  • vesinisa 5y ago
    Well, the decision can always be reversed, but on the outset I would say banning the entire university and publicly naming them is a good start. I don't think this kind of "research" is ethical, and the issue needs to be raised. Banning them is a good opener to engage the instiution in a dialogue.
    • soneil 5y ago
      It seems fair enough to me. They were curious to see what happens, this happens. Giving them a free pass because they're a university would be artificially skewing the results of the research. Low trust and negative trust should be fairly obvious costs to messing with a trust model - you could easily argue this is working as intended.
  • op00to 5y ago
• deleted 5y ago
  [deleted]
• jnxx 5y ago
  > Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. That's the university's problem to fix.
  • deleted 5y ago
    [deleted]
  • shawnz 5y ago
    What's the recourse for them though? Just beg to have the decision reversed?
    • dataflow 5y ago
      Probably that, combined with "we informed the professor of {serious consequences} should this happen again".
    • ttyprintk 5y ago
      The comment about IRB —- institutional research board —- is clear, I think.
      • shawnz 5y ago
        The suggestion about the IRB was made by a third party. Look at the follow up comment from kernel developer Leon Romanovsky. > ... we don't need to do all the above and waste our time to fill some bureaucratic forms with unclear timelines and results. Our solution to ignore all @umn.edu contributions is much more reliable to us who are suffering from these researchers.
        • shawnz 5y ago
          To follow up on my comment here, I think Greg KH's later responses were more reasonable. > ... we have the ability to easily go back and rip the changes out and we can slowly add them back if they are actually something we want to do. > I will be working with some other kernel developers to determine if any of these reverts were actually valid changes, were actually valid, and if so, will resubmit them properly later. ... future submissions from anyone with a umn.edu address should be by default-rejected unless otherwise determined to actually be a valid fix
• walrus01 5y ago
  > I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"
  • Cthulhu_ 5y ago
    If they wanted to do security research, they could have done so in the form of asking the reviewers to help; send them a patch and ask 'Is this something you would accept?', instead of intentionally sending malicious commits and causing static on the commit tree and mailing lists.
    • tapland 5y ago
      Dd they keep track of and submit a list of additions to revert after they managed to get it added? From the looks of it they didn't even when it was heading out to stable releases? That's just using the project with no interest in not causing issues.
      • Verdex 5y ago
        Yeah, so an analogy would be to put human feces into food and then see if the waiter is going to actually give it to the dinning customer. And then if they do, just put a checkmark on a piece of paper and then leave without warning someone that they're about to eat poop.
    • scaladev 5y ago
      Wouldn't that draw more attention to the research patches, compared to a "normal" lkml patch? If you (as a maintainer) expected the patch to be malicious, wouldn't you be extra careful in reviewing it?
      • Dobbs 5y ago
        You don't have to say you are studying the security implications, you could be say you are studying something else like turn around time for patches, or level of critique, or any number of things.
• GoblinSlayer 5y ago
  Forking the kernel should be sufficient for research.
  • hjalle 5y ago
    Not if the research involves the reviewing aspects of open source projects.
    • hellow0rldz 5y ago
      Apparently they aren't doing human experiments, it's only processes and such. So they can easily emulate the processes in-house too!
  • jaywalk 5y ago
    This research is specifically about getting patches accepted into open source projects, so that wouldn't work at all.
    • GoblinSlayer 5y ago
      For other research happening in the university. This particular research is trivial anyway, see https://news.ycombinator.com/item?id=26888417 https://news.ycombinator.com/item?id=26888417
• pmiller2 5y ago
  I find it hard to believe this research passed IRB.
  • bobthechef 5y ago
    How thorough is IRB review? My gut feeling is that these are not necessarily the most conscientious or informed bodies. Add into the mix a proposal that conceals the true nature of what's happening. (All of this ASSUMING that the intent was as described in the thread.)
    • bluGill 5y ago
      They are probably more familiar with medical research and the types of things that go wrong there. Bad ethics in medical situations is well understood, including psychology. However it is hard to figure out how a mechanical engineer could violate ethics.
      • pmiller2 5y ago
        I had to do human subjects research training in grad school, just to be able to handle test score data for a math education project. I literally never saw an actual student the whole time I was working on it.
      • cedilla 5y ago
        To be fair, the consequences of unethical research in medicine or psychology can be much more dire than what happened here.
        • pmiller2 5y ago
          Perhaps more dire than what actually happened, but, can you imagine the consequences if any of those malicious patches had actually stuck around in the kernel? Keep in mind when you think about this that Android, which has an 87% market share globally in smartphones[0] runs on top of a modified Linux kernel. -- [0]: https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/ https://www.statista.com/statistics/272307/market-share-fore...
• duxup 5y ago
  Seems like a bit of a strong response. Universities are large places with lots of professors and people with different ideas, opinions, views, and they don't work in concert, quite the opposite. They're not some corporation with some unified goal or incentives. I like that. That's what makes universities interesting to me. I don't like the standard here of of penalizing or lumping everyone there together, regardless of they contribute in the past, now, in the future or not.
  • tinco 5y ago
    The goal is not penalizing or lumping everyone together. The goal is to have the issue fixed in the most effective manner. It's not the Linux team's responsibility to allow contributions from some specific university, it's the university's. This measure enforces that responsibility. If they want access, they should rectify.
    • duxup 5y ago
      I would then say that the goal and the choice aren't aligned because "penalizing or lumping everyone together" is exactly the choice made.
      • brainwad 5y ago
        They would presumably reconsider blanket ban, if the university says they will prohibit these specific researchers from committing to Linux.
      • jeffffff 5y ago
        the university can easily resolve the issue by firing the professors
        • duxup 5y ago
          The people who are effected by the rule or discouraged by it cannot do so.
        • 5y ago
• xbar 5y ago
  This is not responsible research. This is similar to initiating fluid mechanics experiments on the wings of a Lufthansa A320 in flight to Frankfurt with a load of Austrians. There are a lot of people to feel bad for, but none is at the University of Minnesota. Think of the Austrians.
  • mort96 5y ago
    No, it's totally okay to feel sorry for good, conscientious researchers and students at the University of Minnesota who have been working on the kernel in good faith. It's sad that the actions of irresponsible researchers and associated review boards affect people who had nothing to do with professor Lu's research. It's not wrong for the kernel community to decide to blanket ban contributions from the university. It obviously makes sense to ban contributions from institutions which are known to send intentionally buggy commits disguised as fixes. That doesn't mean you can't feel bad for the innocent students and professors.
    • unanswered 5y ago
      > good, conscientious researchers and students at the University of Minnesota who have been working on the kernel in good faith All you have to do is look at the reverted patches to see that these are either mythical or at least few and far in between.
      • sand500 5y ago
        Didn't they just blanket revert all patches from University of Minnesota? https://news.ycombinator.com/item?id=26889550 https://news.ycombinator.com/item?id=26889550
      • rjayatilleka 5y ago
        To be clear, Linux kernel patches from good UMN researchers and students are rare. We have plenty of great people at the University of Minnesota, they just don't work on the Linux kernel. It's justifiable and natural for our name to be dragged in the mud here, but as a run of the mill software engineer who graduated from UMN, I hope our reputation isn't soured too much.
• Foxboron 5y ago
  It's important to note that they used temporary emails for the patches in this research. It's detailed in the paper. The main problem is that they have (so far) refused to explain in detail how the patches where reviewed and how. I have not gotten any links to any lkml post even after Kangjie Lu personally emailed me to address any concerns.
• some_random 5y ago
  It definitely would suck to be someone at UMN doing legitimate work, but I don't think it's reasonable to ask maintainers to also do a background check on who the contributor is and who they're advised by.
• temac 5y ago
  I don't feel sorry at all. If you want to contribute from there, show that the rogue professor and their students have been prevented from doing further malicious contributions (that is probably at least: from doing any contribution at all during a quite long period -- and that is fair against repeated infractions), and I'm sure that you will be able to contribute back again under the University umbrella. If you don't manage to reach that goal, too bad, but you can contribute on a personal capacity, and/or go work elsewhere.
  • seoaeu 5y ago
    How could a single student or professor possibly achieve that? Under the banner of "academic freedom" it is very hard to get someone fired because you don't like their research. It sounds like you're making impossible demands of unrelated people, while doing nothing to solve the actual problem because the perpetrators now know to just create throwaway emails when submitting patches.