The ultimate problem is that it's easy to fake stuff so you have to use heuristics to see who you can trust. You sort of sum up your threat score and then decide how much attention to apply. Without doing something like that, the transaction costs dominate and certain valuable things can't be done. It's true that Western universities are generally a positive component to that score and students under a professor there are another positive component to the score.

It's like if my wife said "I'm taking the car to get it washed" and then she actually takes the car to the junkyard and sells it. "Ha, you got fooled!". I mean, yes, obviously. She's on the inside of my trust boundary and I don't want to live a life where I'm actually operating in a way immune to this 'exploit'.

I get that others object to the human experimentation part of things and so on, but for me that could be justified with a sufficiently high bar of utility. The problem is that this research is useless.

▲

jovial_cavalier 13 hours ago | parent [-]

No, random anonymous contributors with cheng3920845823@gmail.com as their email address are not as trustworthy as your wife, and blindly merging PRs from them into some of the most security-critical and widely used code in the entire world without so much as running a static analyzer is not reasonable.

▲

arjie 12 hours ago | parent [-]

Oh I misunderstood the sections in the article about the umn.edu email stuff. My mistake. The actual course of events:

1. Prof and students make fake identities

2. They submit these secret vulns to Greg KH and friends

3. Some of these patches are accepted

4. They intervene at this point and reveal that the patches are malicious

5. The patches are then not merged

6. This news comes out and Greg KH applies big negative trust score to umn.edu

7. Some other student submits a buggy patch to Greg KH

8. Greg KH assumes that it is more research like this

9. Student calls it slander

10. Greg KH institutes policy for his tree that all umn.edu patches should be auto-rejected and begins reverts for all patches submitted in the past by such emails

To be honest, I can't imagine any other such outcome could have occurred. No one likes being cheated out of work that they did, especially when a lot of it is volunteer work. But I was wrong to say the research was useless. It does demonstrate that identities without provenance can get malicious code into the kernel.

Perhaps what we really need is a Social Credit Score for OSS ;)

▲

caycep 12 hours ago | parent | next [-]

Actually, I think #7 is one of the same students working for the professor. So GKH is correct in assuming it's more of the same.

Research can be non-useless but also unethical at the same time...

▲

yjftsjthsd-h 12 hours ago | parent | prev | next [-]

> 3. Some of these patches are accepted

> 4. They intervene at this point and reveal that the patches are malicious

> 5. The patches are then not merged

It's not clear to me that they revealed anything, just that they did fix the problems:

> In their paper, Lu and Wu claimed that none of their bugs had actually made it to the Linux kernel — in all of their test cases, they’d eventually pulled their bad patches and provided real ones. Kroah-Hartman, of the Linux Foundation, contests this — he told The Verge that one patch from the study did make it into repositories, though he notes it didn’t end up causing any harm.

(I'm only working from this article, though, so feel free to correct me)

▲

arjie 12 hours ago | parent | next [-]

You know there's a lot of he-said she-said here. The truth is that I was repeating there what they claimed in the paper which is that they intervened prior to merge to mainline.

▲

yjftsjthsd-h 11 hours ago | parent [-]

My point was that (the article claims that) they didn't "reveal that the patches are malicious" at that point. Revert yes, reveal no.

	▲	worthless-trash 4 hours ago \| parent \| next [-]
		IIRC one of them actually introduced a memory corrupting problem. I don't know if it got accepted or not. I remember seeing the issue and rejecting the patch for rhel.
	▲	arjie 11 hours ago \| parent \| prev [-]
		Man, what a mess.

▲

jovial_cavalier 12 hours ago | parent | prev [-]

I don't believe they revealed that they were hypocrite commits at the time of their acceptance, that was only revealed when the paper was put on a preprint server. But they did point out the problems to maintainers before the changes were mainlined.

▲

jovial_cavalier 12 hours ago | parent | prev [-]

>No one likes being cheated out of work that they did, especially when a lot of it is volunteer work.

You know what would really be wasteful of volunteer hours? Instituting a policy whereby the community has to trawl through 20 years of commits from umn.edu addresses and manually review them for vulnerabilities even though you have no reasonable expectation that such commits are likely to contain malicious code and you're actually just butthurt. (they found nothing after weeks of doing this btw)

	▲	imtringued 14 minutes ago \| parent \| next [-]
		That professor just destroyed the ability to trust public institutions like universities to not be malicious actors. You can't restore that trust unless you comb through everything. If you just let them go, you now have to distrust every single university by default, which is even more expensive.
	▲	dessimus 11 hours ago \| parent \| prev \| next [-]
		But what if the next paper is about then about the bad patch they put in 15 years ago and it still hasn't been noticed? UMN has created a situation that now calls into question everything that has contributed by UMN in showing bad-faith in retroactively approving Lu's actions.
	▲	yjftsjthsd-h 11 hours ago \| parent \| prev [-]
		> even though you have no reasonable expectation that such commits are likely to contain malicious code and you're actually just butthurt Other than the tiny bit where that's not true. An institution just demonstrated that they are willing to submit malicious code, and don't feel any need to tell you that they did so (even after the fact). It's perfectly reasonable to ask if they've done this before.