4 ms·

The guilt by association here is now approaching Biblical scales. Like the guy in the comments who wants to close down the entire Computer Science and Electrica

The guilt by association here is now approaching Biblical scales. Like the guy in the comments who wants to close down the entire Computer Science and Electrical Engineering departments at UMN, which probably employ/educate the best part of a thousand people. Ha! In general, the fury and seethe which this experiment inspired is amazing. IMO the real disgrace is not the experiment itself, but the response. The kernel developers need to stop being martyrs and playing blame games. They need to be rational and take responsibility for improving their own procedures. Because, if they didn't already have them, governments now have entire departments studying how to use deliberate vulnerabilities in open source projects, for military intelligence and other purposes. And they will not be deterred by the continued public flogging of the University of Minnesota.

belval 5y ago
Most maintainers are volunteer, meaning that they spend their evenings, weekends and holidays developing the kernel because they like it, it gives them a sense of worth and fulfillment that can be hard to come across. I don't know if you've ever talked to one, but they take a real pride in their work, most make a pitiful salary in comparison to FAANG levels but they still do it because it is full of interesting challenges you can't find anywhere else. UMN broke that trust. No one is asking the departements to close least of all the maintainers, but you have to understand that kernel devs are not a faceless machine. They spend their limited time on something that is used to make a prodigious amount of money, while never really getting any. In that context they are more than within their rights to be livid.
- nitrogen 5y ago
  In that context they are more than within their rights to be livid. They do, and to a very largr extent the same exact overreaction happens in private orgs and we just get to see it when it's the Linux kernel. But at the end of the day, there was an overreaction, and it was public. Both the UMN and the kernel maintainers need to step up and make improvements now, and move forward with level heads. Have any of the kernel maintainers acknowledged the primary concern behind the misguided research? That is, (quoting parent comment) "governments now have entire departments studying how to use deliberate vulnerabilities in open source projects"?
- greenwich26 5y ago
  I don't dispute that the researchers were dishonest and broke the trust of the kernel maintainers. So they can be a bit peeved off at UMN. But is this sort of thing not the reality of their operation? That liars exist in the world? I don't really see what the volunteer part has to do with it. If anything it means they have less to complain about. I mean...most soldiers are volunteers, which would make it even more absurd, if someone signed up to be a soldier, and then whined and complained when enemy soldiers shot at him. It seems equally obvious to me, that an open network should be assumed to have malicious actors on it, as that a battlefield should be assumed to have enemies on it. Obviously you don't have to like the enemies.
  - shkkmo 5y ago
    Trust is not a binary. You must trust contributors to your project to some extent. If you don't extend some trust, you can't have contributors. That level of trust is then adjusted off that base level based on experience. It is perfectly reasonable to drop someone below your base level of trust if they lie to you. This doesn't necessarily mean that the base level of trust needs to be adjusted. In this case, the review process caught all the known harmful commits (which were from anonymous emails so recieved base level trust) and thus the base line level of trust seems to be working.
  - belval 5y ago
    I don't have internal info so this is just an hypothesis, but I think they absolutely do expect adversarial commits and if you tried to get something accepted today with no affiliation or anything you would need to talk to multiple maintainers and your commits would be under scrutiny. Here the "contributors" had done multiple commits and were coming from a university that had previously upstreamed several commits. There was and should be an expectation of trust because you can't scrutinize every commit for several hours (they just don't have them enough maintainers for it).
asddubs 5y ago
I don't think it's really fair to pin some random person's bad take on the kernel developers. disproportionate calls for mob justice have always and will always be popular, especially on the internet where it's very easy to leave casual comments without thinking about it too hard (and you can never really tell someones age)
bronson 5y ago
They lied in their abstract [0], they lied to their IRB, and Kangjie Lu's aspirations have been wasting a lot of Linux maintainer time. The real disgrace was the experiment. The response was fairly natural for humans with imperfect information being experimented on. Please be more specific. How do you think the Linux kernel maintainers should improve their procedures to prevent clownshows like this in the future? No points for mentioning things that they already do or assuming infinite maintainer hours. [0]: https://twitter.com/SarahJamieLewis/status/1384876050207940608?s=20 https://twitter.com/SarahJamieLewis/status/13848760502079406...
- greenwich26 5y ago
  I just don't understand why open source software can continue with the assumption that every single contributor is honest. Imagine if this philosophy was applied to, say, cryptography or network security. What would be the state of encryption algorithms and key exchange protocols and so on, if their developers had a meltdown at the mere suggestion of there existing a liar? Since the Linux kernel is installed on many millions of computers, it is obviously pretty important that it doesn't have bugs in it. Certainly not malicious bugs. And if all it takes is a couple grad students and an assistant prof to get them in...well, that reflects very poorly on the state of kernel maintenance, to me. Which seems far more important and deserving of attention, than endlessly arraigning three clueless guys at some university. I'm not in a position to be more specific about what should be fixed. But, what would your answer be to your query? Apparently, do nothing, and assume that everyone in the world is honest, while writing self-indulgent "public letters" about it? How is that going to help when the CCP tries to insert surveillance into the kernel? Or when Russian hackers try to get exploits and ransomware in there?
  - shkkmo 5y ago
    > assumption that every single contributor is honest. There is no such assumption and it has been well known for a long time that such an assumption would be harmful. > if all it takes is a couple grad students and an assistant prof to get them in There were 0 malicious commits that made it through the review process (since the paper was incompetent as well as unethical.) You seem to be missing some basic facts here. Filling in those gap would help you partipate more productively in the conversation.

belval 5y ago

Most maintainers are volunteer, meaning that they spend their evenings, weekends and holidays developing the kernel because they like it, it gives them a sense of worth and fulfillment that can be hard to come across. I don't know if you've ever talked to one, but they take a real pride in their work, most make a pitiful salary in comparison to FAANG levels but they still do it because it is full of interesting challenges you can't find anywhere else. UMN broke that trust. No one is asking the departements to close least of all the maintainers, but you have to understand that kernel devs are not a faceless machine. They spend their limited time on something that is used to make a prodigious amount of money, while never really getting any. In that context they are more than within their rights to be livid.

nitrogen 5y ago
In that context they are more than within their rights to be livid. They do, and to a very largr extent the same exact overreaction happens in private orgs and we just get to see it when it's the Linux kernel. But at the end of the day, there was an overreaction, and it was public. Both the UMN and the kernel maintainers need to step up and make improvements now, and move forward with level heads. Have any of the kernel maintainers acknowledged the primary concern behind the misguided research? That is, (quoting parent comment) "governments now have entire departments studying how to use deliberate vulnerabilities in open source projects"?
greenwich26 5y ago
I don't dispute that the researchers were dishonest and broke the trust of the kernel maintainers. So they can be a bit peeved off at UMN. But is this sort of thing not the reality of their operation? That liars exist in the world? I don't really see what the volunteer part has to do with it. If anything it means they have less to complain about. I mean...most soldiers are volunteers, which would make it even more absurd, if someone signed up to be a soldier, and then whined and complained when enemy soldiers shot at him. It seems equally obvious to me, that an open network should be assumed to have malicious actors on it, as that a battlefield should be assumed to have enemies on it. Obviously you don't have to like the enemies.
- shkkmo 5y ago
  Trust is not a binary. You must trust contributors to your project to some extent. If you don't extend some trust, you can't have contributors. That level of trust is then adjusted off that base level based on experience. It is perfectly reasonable to drop someone below your base level of trust if they lie to you. This doesn't necessarily mean that the base level of trust needs to be adjusted. In this case, the review process caught all the known harmful commits (which were from anonymous emails so recieved base level trust) and thus the base line level of trust seems to be working.
- belval 5y ago
  I don't have internal info so this is just an hypothesis, but I think they absolutely do expect adversarial commits and if you tried to get something accepted today with no affiliation or anything you would need to talk to multiple maintainers and your commits would be under scrutiny. Here the "contributors" had done multiple commits and were coming from a university that had previously upstreamed several commits. There was and should be an expectation of trust because you can't scrutinize every commit for several hours (they just don't have them enough maintainers for it).

asddubs 5y ago

I don't think it's really fair to pin some random person's bad take on the kernel developers. disproportionate calls for mob justice have always and will always be popular, especially on the internet where it's very easy to leave casual comments without thinking about it too hard (and you can never really tell someones age)

bronson 5y ago

They lied in their abstract [0], they lied to their IRB, and Kangjie Lu's aspirations have been wasting a lot of Linux maintainer time. The real disgrace was the experiment. The response was fairly natural for humans with imperfect information being experimented on. Please be more specific. How do you think the Linux kernel maintainers should improve their procedures to prevent clownshows like this in the future? No points for mentioning things that they already do or assuming infinite maintainer hours. [0]: https://twitter.com/SarahJamieLewis/status/1384876050207940608?s=20 https://twitter.com/SarahJamieLewis/status/13848760502079406...

greenwich26 5y ago
I just don't understand why open source software can continue with the assumption that every single contributor is honest. Imagine if this philosophy was applied to, say, cryptography or network security. What would be the state of encryption algorithms and key exchange protocols and so on, if their developers had a meltdown at the mere suggestion of there existing a liar? Since the Linux kernel is installed on many millions of computers, it is obviously pretty important that it doesn't have bugs in it. Certainly not malicious bugs. And if all it takes is a couple grad students and an assistant prof to get them in...well, that reflects very poorly on the state of kernel maintenance, to me. Which seems far more important and deserving of attention, than endlessly arraigning three clueless guys at some university. I'm not in a position to be more specific about what should be fixed. But, what would your answer be to your query? Apparently, do nothing, and assume that everyone in the world is honest, while writing self-indulgent "public letters" about it? How is that going to help when the CCP tries to insert surveillance into the kernel? Or when Russian hackers try to get exploits and ransomware in there?
- shkkmo 5y ago
  > assumption that every single contributor is honest. There is no such assumption and it has been well known for a long time that such an assumption would be harmful. > if all it takes is a couple grad students and an assistant prof to get them in There were 0 malicious commits that made it through the review process (since the paper was incompetent as well as unethical.) You seem to be missing some basic facts here. Filling in those gap would help you partipate more productively in the conversation.