4 ms·

Literally nothing. Instead of actual actions to improve the process it's only feel-good actions without any actual benefit to the kernel's security.

thenoblesunfish 6y ago
The point is to make it very obviously not worth it to conduct this kind of unethical research. I don't think UMN is going to be eager to have this kind of attention again. People could always submit bogus patches from random email addresses - this removes the ability to do it under the auspices of a university.
- Avamander 6y ago
  The ethical aspect is separate from the practical aspect that is kernel security. Sabotage is a very real risk but we're discussing ethics of demonstrating the risk instead of potential remediation, that's dangerous and foolish.
- d110af5ccf 6y ago
  > this removes the ability to do it under the auspices of a university It really doesn't though. You can claim ownership of that email address in the published manuscript. For that matter, you could even publish the academic article under a pen name if you wanted to. But after seeing how the maintainers responded here, you'd better make sure that any "real" contributions you make aren't associated with the activity in any way.
rincebrain 6y ago
You keep posting all over this discussion about how the Linux maintainers are making a poor choice and shooting the messenger. What would you like them to do instead or in addition to this?
- GoblinSlayer 6y ago
  Indeed the situation is bad, nothing can be done. At the very least as long as they can make unintentional vulnerabilities, they are defenseless against intentional ones, and fixing only the former is already a very big deal.
- Avamander 6y ago
  > What would you like them to do instead or in addition to this? Update the processes and tools to try and catch such malicious infiltrators. Lynching researchers isn't fixing the actual issue right now.
  - yjftsjthsd-h 6y ago
    > Update the processes and tools to try and catch such malicious infiltrators. How?
    - Avamander 6y ago
      That's what I'm saying kernel maintainers should figure out.
      - michaelt 6y ago
        Step 1: When a malicious infiltrator is identified, mount their head on a spike as a warning to others.
  - rincebrain 6y ago
    I saw at least one developer lamenting that they were going to potentially bring up mechanisms for having to treat every committer as malicious by default instead of not at the next kernel summit, so it's quite possible that's going to take place.
    - d110af5ccf 6y ago
      > lamenting that they were going to potentially bring up mechanisms for having to treat every committer as malicious by default I think "lamenting" is very much the wrong attitude here. Given all the things that make use of Linux today that seems like the only sane approach to me.
      - detaro 6y ago
        If people insisted on a kernel like that, that's what they'd fund and use. But apparently that's not their priority.
yowlingcat 6y ago
I think you're getting heavily downvoted with your comments on this submission because you seem to be missing a critical sociological dimension of assumed trust. If you submit a patch from a real name email, you get an extra dimension of human trust and likewise an extra dimension of human repercussions if your actions are deemed to be malicious. You're criticizing the process, but the truth is that without a real name email and an actual human being's "social credit" to be burned, there's no proof these researchers would have achieved the same findings. The more interesting question to me is if they had used anonymous emails, would they have achieved the same results? If so, there might be some substance to your contrarian views that the process itself is flawed. But as it stands, I'm not sure that's the case. Why? Well, look at what happened. The maintainers found out and blanket banned bad actors. Going to be a little hard to reproduce that research now, isn't it? Arbitraging societal trust for research doesn't just bring ethical challenges but /practical/ ones involving US law and standards for academic research.
- Avamander 6y ago
  > actual human being's "social credit" to be burned How are kernel maintainers competent in detecting a real person vs. fake real person? Why is there any inherit trust? It's clear the system is fallible, but at least now people are humbled enough to not instantly dismiss the risk. > The maintainers found out and blanket banned bad actors. With collateral damage.
  - burnished 6y ago
    the mail server is usually a pretty good indicator. I'm not an expert but you generally can't get a university email address without being enrolled.
    - d110af5ccf 6y ago
      So a malicious actor can just take a single online summer class. Bonus points if they manage to use a fake ID to enroll at the university.
burnished 6y ago
Well, it seems unlikely that any other universities will fund or support copy cat studies. And I don't mean in the top-down institutional sense I mean in the self-selecting sense. Students will not see messing with the linux kernel as being a viable research opportunity and will not do it. That doesn't seem to be 'feel-good without any actual benefit to the kernel's security'. Sounds like it could function as an effective deterent.

thenoblesunfish 6y ago

The point is to make it very obviously not worth it to conduct this kind of unethical research. I don't think UMN is going to be eager to have this kind of attention again. People could always submit bogus patches from random email addresses - this removes the ability to do it under the auspices of a university.

Avamander 6y ago
The ethical aspect is separate from the practical aspect that is kernel security. Sabotage is a very real risk but we're discussing ethics of demonstrating the risk instead of potential remediation, that's dangerous and foolish.
d110af5ccf 6y ago
> this removes the ability to do it under the auspices of a university It really doesn't though. You can claim ownership of that email address in the published manuscript. For that matter, you could even publish the academic article under a pen name if you wanted to. But after seeing how the maintainers responded here, you'd better make sure that any "real" contributions you make aren't associated with the activity in any way.

rincebrain 6y ago

You keep posting all over this discussion about how the Linux maintainers are making a poor choice and shooting the messenger. What would you like them to do instead or in addition to this?

GoblinSlayer 6y ago
Indeed the situation is bad, nothing can be done. At the very least as long as they can make unintentional vulnerabilities, they are defenseless against intentional ones, and fixing only the former is already a very big deal.
Avamander 6y ago
> What would you like them to do instead or in addition to this? Update the processes and tools to try and catch such malicious infiltrators. Lynching researchers isn't fixing the actual issue right now.
- yjftsjthsd-h 6y ago
  > Update the processes and tools to try and catch such malicious infiltrators. How?
  - Avamander 6y ago
    That's what I'm saying kernel maintainers should figure out.
    - michaelt 6y ago
      Step 1: When a malicious infiltrator is identified, mount their head on a spike as a warning to others.
- rincebrain 6y ago
  I saw at least one developer lamenting that they were going to potentially bring up mechanisms for having to treat every committer as malicious by default instead of not at the next kernel summit, so it's quite possible that's going to take place.
  - d110af5ccf 6y ago
    > lamenting that they were going to potentially bring up mechanisms for having to treat every committer as malicious by default I think "lamenting" is very much the wrong attitude here. Given all the things that make use of Linux today that seems like the only sane approach to me.
    - detaro 6y ago
      If people insisted on a kernel like that, that's what they'd fund and use. But apparently that's not their priority.

yowlingcat 6y ago

I think you're getting heavily downvoted with your comments on this submission because you seem to be missing a critical sociological dimension of assumed trust. If you submit a patch from a real name email, you get an extra dimension of human trust and likewise an extra dimension of human repercussions if your actions are deemed to be malicious. You're criticizing the process, but the truth is that without a real name email and an actual human being's "social credit" to be burned, there's no proof these researchers would have achieved the same findings. The more interesting question to me is if they had used anonymous emails, would they have achieved the same results? If so, there might be some substance to your contrarian views that the process itself is flawed. But as it stands, I'm not sure that's the case. Why? Well, look at what happened. The maintainers found out and blanket banned bad actors. Going to be a little hard to reproduce that research now, isn't it? Arbitraging societal trust for research doesn't just bring ethical challenges but /practical/ ones involving US law and standards for academic research.

Avamander 6y ago
> actual human being's "social credit" to be burned How are kernel maintainers competent in detecting a real person vs. fake real person? Why is there any inherit trust? It's clear the system is fallible, but at least now people are humbled enough to not instantly dismiss the risk. > The maintainers found out and blanket banned bad actors. With collateral damage.
- burnished 6y ago
  the mail server is usually a pretty good indicator. I'm not an expert but you generally can't get a university email address without being enrolled.
  - d110af5ccf 6y ago
    So a malicious actor can just take a single online summer class. Bonus points if they manage to use a fake ID to enroll at the university.

burnished 6y ago

Well, it seems unlikely that any other universities will fund or support copy cat studies. And I don't mean in the top-down institutional sense I mean in the self-selecting sense. Students will not see messing with the linux kernel as being a viable research opportunity and will not do it. That doesn't seem to be 'feel-good without any actual benefit to the kernel's security'. Sounds like it could function as an effective deterent.