4 ms·

I agree with this post > Unless the researchers are lying (which I've not seen a clear indication of), the 190 patches you have selected here are nothing more

I agree with this post > Unless the researchers are lying (which I've not seen a clear indication of), the 190 patches you have selected here are nothing more than collateral damage while you are completely missing the supposed patch submission addresses from which the malicious patches were sent! This all really sounds like a knee-jerk reaction to thier posting. I have to say, I think it's the wrong reaction to have. https://lore.kernel.org/lkml/18edc472a95f1d4efe3ef40cc9b8d2611d4ab990.camel@redhat.com/ https://lore.kernel.org/lkml/18edc472a95f1d4efe3ef40cc9b8d26... Greg Kroah-Hartman’s poorly thought out bulk reversion is the bigger waste of time here.

genmud 5y ago
If someone, or in this case a set of affiliated someones, have proven to do malicious or ethically questionable things, trust has to be earned. The risk of letting things stay without extensive verification is not worth it and I definitely don't consider this a kneejerk reaction given the potential perception risks.
- nuclearnice1 5y ago
  Hypocrite patches came from Gmail. Banned umn mail. Because that’s going to reduce risk?
  - tmp538394722 5y ago
    It’s not so much that they banned umn email, as it is they banned the university of Minnesota. This particular act is about avoiding the risk of researchers wasting kernel developers time. As evinced by the response, it seems really unlikely that other institutions would think it’s a good idea to perform experiments on the kernel devs in the future.
    - x3__ 5y ago
      You do know that one can contribute without having to use their institution email address ?
      - tmp538394722 5y ago
        Yes, I do know that. The policy is not about them being physically prevented from emailing from not-a-umn-researcher@yahoo.com. It’s a symbolic policy, but I would be extremely surprised if a university flouted a clear and explicit ban on their participation.
    - nuclearnice1 5y ago
      Most of the reverted commits are fine by inspection and the researched insist there were 3 hypocrite submissions that didn’t get merged. So the idea is to collectively punish the mostly innocent people who wrote the 190 good commits, spending a huge amount of developer time checking them or losing the fixes to prevent other institutions from doing this? Does reverting nearly 200 good patches seem out of proportion relative to 3 unmerged hypocrite commits?
      - tmp538394722 5y ago
        That’s a fair question about proportionality. I don’t have any special insight into the kernel team, but I think the response is as much about making an example of the university as it is about removing any plausibly contaminated commits, in which case it makes sense to be somewhat extreme. Others are saying the entire research team should be fired. It’s interesting that the former (reverting the commits) is something the kernel devs can do to publish the university, while the latter (firing researchers) is something the university can do to punish the researchers. Who messed up? The researchers or the university who approved their research? Probably enough blame to go around.
        nuclearnice1 5y ago
        Proportionality is one aspect. Punishing the right people is another. If you’re an UMN patch submitter who has just seen your work thrown away because of the actions of some researchers you don’t know and some kernel maintainer you don’t know, you’d be rightly upset. Punishing the entire university for the actions of a few. I think it’s a bad idea: https://en.m.wikipedia.org/wiki/Collective_punishment https://en.m.wikipedia.org/wiki/Collective_punishment
        rincebrain 5y ago
        FWIW, there are no patches committed that I can find since 2013 that are not by people who are or were in the relevant lab at UMN. Maybe my research is flawed, but I don't think the bulk revert is currently hitting anyone but them. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.16&qt=author&q=umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
shkkmo 5y ago
The researchers already lied when they conducted the study. What you are proposing is that we now should trust them to tell us the extent of their previous duplicitousness. The most recent patch, which triggered the bad, has not been explained in good faith and it seems likely there were mistruths involved in that exchange as well. So while it is absolutely a waste of time to have to go back through those 190 commits, the responsibility for that falls squarely on the researchers who broke that trust, not on the Greg fro refusing to re-extend that trust in the face of continued sketchy behaviors.
- nuclearnice1 5y ago
  Why shouldn’t we trust them on the extent of their lies? Except three research commits, everything they have said has been true. Given how few of the 190 have turned out wrong, given the timeline of the research relative, given the existing static analysis paper. Did Aditya Pakki write two entire papers about static analysis as cover for continuing this hypocrite commit research? Or did Aditya Pakki submit a bad patch in good faith and Greg Kroah-Hartman misunderstood and then overreacted with this mass revert? I think the latter is more plausible. Otherwise, why stop at 190? The hypocrite commits came from Gmail. Logically, we can’t trust the researchers so we need to revert all Gmail commits. Wait they could Be infiltrating other universities, we should ban university commits everywhere. That would be a lot of work. So Greg picked a medium set of patches that expressed his power and outrage but had no real effect. The point is the particular set of commits he chose aren’t risky (by inspection we know they are good) and aren’t related to the hypocrite commits. So many innocent people are having their work thrown away because Greg is angry. Note that we have only seen the simple to revert patches. There are 68 complex umn patches that have not been reverted. I expect they won’t because this is mainly theater. The commits are good but Greg wants to be show how angry he is. My impression is we are just living through some kernel maintainer lashing out because he was embarrassed by the failed review process and mixed up the buggy static commits with the hypocrite research. Admitting you’re wrong is hard, so I don’t expect Greg to do that.
  - shkkmo 5y ago
    Let's flip this on it's head and posit a counterfactual. Let's say that Greg does nothing and re-extend trust. Then vulnerabilities are exploited that exist due to additional bad patches submitted by this researcher. Greg would be rightly held to account for failing to his due diligence when he had clear evidence of malicious commits. So even if all the the commits are good and even if Greg believes that, he has still been forced into these actions by the violations of trust committed by the researchers. You are correct that the line as to what patches is a bit arbitrary, but it was always going to be. The research was conducted by the University so it seem the most reasonable place to draw the line to me. I have still yet to see any explanation from the researchers as to why that "bad patch" happened, didn't include a reference to the automated tool as required, or what tool it even was. I do think Greg is angry, but I don't think your insistence asscribing Greg's anger as his primary motivation is fair to him or consistent with HN guidelines on comments. I think you could make points about reverting commits without what seem to me like unnecessary personal attacks.

genmud 5y ago

If someone, or in this case a set of affiliated someones, have proven to do malicious or ethically questionable things, trust has to be earned. The risk of letting things stay without extensive verification is not worth it and I definitely don't consider this a kneejerk reaction given the potential perception risks.

nuclearnice1 5y ago
Hypocrite patches came from Gmail. Banned umn mail. Because that’s going to reduce risk?
- tmp538394722 5y ago
  It’s not so much that they banned umn email, as it is they banned the university of Minnesota. This particular act is about avoiding the risk of researchers wasting kernel developers time. As evinced by the response, it seems really unlikely that other institutions would think it’s a good idea to perform experiments on the kernel devs in the future.
  - x3__ 5y ago
    You do know that one can contribute without having to use their institution email address ?
    - tmp538394722 5y ago
      Yes, I do know that. The policy is not about them being physically prevented from emailing from not-a-umn-researcher@yahoo.com. It’s a symbolic policy, but I would be extremely surprised if a university flouted a clear and explicit ban on their participation.
  - nuclearnice1 5y ago
    Most of the reverted commits are fine by inspection and the researched insist there were 3 hypocrite submissions that didn’t get merged. So the idea is to collectively punish the mostly innocent people who wrote the 190 good commits, spending a huge amount of developer time checking them or losing the fixes to prevent other institutions from doing this? Does reverting nearly 200 good patches seem out of proportion relative to 3 unmerged hypocrite commits?
    - tmp538394722 5y ago
      That’s a fair question about proportionality. I don’t have any special insight into the kernel team, but I think the response is as much about making an example of the university as it is about removing any plausibly contaminated commits, in which case it makes sense to be somewhat extreme. Others are saying the entire research team should be fired. It’s interesting that the former (reverting the commits) is something the kernel devs can do to publish the university, while the latter (firing researchers) is something the university can do to punish the researchers. Who messed up? The researchers or the university who approved their research? Probably enough blame to go around.
      - nuclearnice1 5y ago
        Proportionality is one aspect. Punishing the right people is another. If you’re an UMN patch submitter who has just seen your work thrown away because of the actions of some researchers you don’t know and some kernel maintainer you don’t know, you’d be rightly upset. Punishing the entire university for the actions of a few. I think it’s a bad idea: https://en.m.wikipedia.org/wiki/Collective_punishment https://en.m.wikipedia.org/wiki/Collective_punishment
        rincebrain 5y ago
        FWIW, there are no patches committed that I can find since 2013 that are not by people who are or were in the relevant lab at UMN. Maybe my research is flawed, but I don't think the bulk revert is currently hitting anyone but them. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.16&qt=author&q=umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

shkkmo 5y ago

The researchers already lied when they conducted the study. What you are proposing is that we now should trust them to tell us the extent of their previous duplicitousness. The most recent patch, which triggered the bad, has not been explained in good faith and it seems likely there were mistruths involved in that exchange as well. So while it is absolutely a waste of time to have to go back through those 190 commits, the responsibility for that falls squarely on the researchers who broke that trust, not on the Greg fro refusing to re-extend that trust in the face of continued sketchy behaviors.

nuclearnice1 5y ago
Why shouldn’t we trust them on the extent of their lies? Except three research commits, everything they have said has been true. Given how few of the 190 have turned out wrong, given the timeline of the research relative, given the existing static analysis paper. Did Aditya Pakki write two entire papers about static analysis as cover for continuing this hypocrite commit research? Or did Aditya Pakki submit a bad patch in good faith and Greg Kroah-Hartman misunderstood and then overreacted with this mass revert? I think the latter is more plausible. Otherwise, why stop at 190? The hypocrite commits came from Gmail. Logically, we can’t trust the researchers so we need to revert all Gmail commits. Wait they could Be infiltrating other universities, we should ban university commits everywhere. That would be a lot of work. So Greg picked a medium set of patches that expressed his power and outrage but had no real effect. The point is the particular set of commits he chose aren’t risky (by inspection we know they are good) and aren’t related to the hypocrite commits. So many innocent people are having their work thrown away because Greg is angry. Note that we have only seen the simple to revert patches. There are 68 complex umn patches that have not been reverted. I expect they won’t because this is mainly theater. The commits are good but Greg wants to be show how angry he is. My impression is we are just living through some kernel maintainer lashing out because he was embarrassed by the failed review process and mixed up the buggy static commits with the hypocrite research. Admitting you’re wrong is hard, so I don’t expect Greg to do that.
- shkkmo 5y ago
  Let's flip this on it's head and posit a counterfactual. Let's say that Greg does nothing and re-extend trust. Then vulnerabilities are exploited that exist due to additional bad patches submitted by this researcher. Greg would be rightly held to account for failing to his due diligence when he had clear evidence of malicious commits. So even if all the the commits are good and even if Greg believes that, he has still been forced into these actions by the violations of trust committed by the researchers. You are correct that the line as to what patches is a bit arbitrary, but it was always going to be. The research was conducted by the University so it seem the most reasonable place to draw the line to me. I have still yet to see any explanation from the researchers as to why that "bad patch" happened, didn't include a reference to the automated tool as required, or what tool it even was. I do think Greg is angry, but I don't think your insistence asscribing Greg's anger as his primary motivation is fair to him or consistent with HN guidelines on comments. I think you could make points about reverting commits without what seem to me like unnecessary personal attacks.