Not really. Everyone knows this flaw exists, the interesting part is how to fix it. Did you read the "suggestions" the researchers made in their paper[1]? They're clueless.
It's like pointing out that buildings can be robbed by breaking their windows. No shit. What do you want to do about it?
[1] https://twitter.com/SarahJamieLewis/status/13848800341465743...
Fair enough. The kernel maintainers are probably much more aware of this than the average open source project. Maybe for some projects it would change their mindset from knowing that this could be happening, to knowing that this will be happening.
Maybe it's a pipe dream, but I have a feeling it could lead to discussions of "what could we have done to catch this automatically," which in turn would lead to better static analysis tools.
Edit: It would be about as useful as pen testing that includes social engineering. That is to say, everyone knows there are dishonest people, but they may not be aware of some of the techniques they use.
It did do that, at least twenty years ago. Static analysis tooling is a huge, active area of research and the kernel is frequently a target of that research. Ditto for other areas like language development (see the recent work on getting Rust into the kernel). If these students had tried making real contributions to those areas, I'm sure they would have been welcome. But that kind of work is difficult and requires real research and development, which these students aren't interested in and/or capable of. So we got this trash instead, and now hopefully you understand the harsh reaction to it.
I do wonder if they would have published if they didn't expect disclosure by angry Linux maintainers, i.e. if they really believe they were weakly successful. Generally, I think this is the type of finding that normally gets lost if there's no pre-disclosure.
True as far as it goes, but the most valuable failing research is that which fails to produce an expected positive result.
Next most valuable is failing to corroborate a novel hypothesis (which is probably what you meant).
When you get an expected result, you haven't learned much, regardless of whether you were (or should have been) expecting success OR failure (with the exception being getting more, or more accurate, data that narrows error bars).
Signed, UMN Researchers.
Edit: Wait, the cops are here. We sincerely apologize for any harm our research group did to your business. Our goal was to identify issues with the windows on your buildings and we are very sorry that the method used in the “smashing windows to take cash” paper was inappropriate.
More like they posted on your facebook pro-<insert your kink here> messages. There's some value in grounding the analogy in reality.
> I think the cash theft is analogous to the dev time the researchers wasted.
That's a fantasy that developers would like to believe because they put an inappropriate valuation on the the time spent on software. The inability to face this, has been disturbing from the start.
If you're messing with someone's systems, or (as in this case) with someone's processes, you don't get to claim to be the good guy unless they agreed to it before the fact. It's not rocket science.