71–80 of 332 posts
Being unaware of whatever this is, until this HN post just now, I'm still in the dark as exactly what was being done which was apparently unethical since the statement doesn't mention any details. Anyone have any details on what the issue is?
Earlier quoted context omitted.
isn't it just a form of red teaming? has red teaming fallen out of fashion?
red teaming without approval of the target org is out of fashion, yes.
but honestly, it seems like valuable research to me. it's unfortunate that it took some time away from busy kernel developers, and it's unfortunate that it ultimately makes the project look worse...
...but isn't that supposed to be part of the promise behind open source? it wouldn't surprise me if i learned that management of private orgs hire security firms to do this sort of thing. where does that come from in foss land, other than the ethers of others tinkering, researching and experimenting?
i think this whole calling for the researchers heads business is overblown. i read their paper, it looks like they approached the situation quite ethically to me.
Earlier quoted context omitted.
I would argue that first requires investigation. They probably just have a bunch of angry emails to go on at this point and haven’t looked in detail at anything else.
> I would argue that first requires investigation. Why do you think that enough of an investigation hasn't been performed in order to understand culpability? Thay already know what happened and want to learn why it was approved. That was what their comment said. Take a look at the actual PDF from the researchers , "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Comm…
The "if needed" tells me they aren't sure what if anything is wrong yet. It would surprise me if they have done that much of an investigation in the few hours since they might have learned about this beyond scheduling meetings with involved parties and compiling relevant documents in a folder.
I think they are at the point of having a bunch of angry emails and a few news articles from certain publications. I don't blame them wanting a bit more than that before saying anything.
Earlier quoted context omitted.
> I would argue that first requires investigation. Why do you think that enough of an investigation hasn't been performed in order to understand culpability? Thay already know what happened and want to learn why it was approved. That was what their comment said. Take a look at the actual PDF from the researchers , "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Comm…
The prof overseeing the paper clarified that they initially did not seek IRB approval, and then received an IRB exemption [0]. I'd want to ask the IRB why they approved that, for starters. Maybe because they'd already done the research and hoped it would blow over, vs. the controversy of rejecting it when they'd already done the work? 0: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
We need to make sure to be supportive of people making mistakes and learning from them instead of raising pitchforks for every misstep. Failure is never completely avoidable and responding properly to failure is way more important than never failing.
Now we wait for the IEEE statement. They will release a statement, right?
I found these statements by the associate department head interesting: https://twitter.com/lorenterveen/status/1384955467051454466 > I do work in Social Computing, and this situation is directly analogous to a number of incidents on Wikipedia quite awhile ago that led to that community and researchers reaching an understanding on research methods that are and are not acceptable. and https://twitter.com/lorenterveen/s…
Too bad he's not in a position of power to implement that additional review to CS department research.
Eh, I work at a uni. This came from a dept head. The university is taking it seriously?? Doubt it. Now, when a Dean puts up a webpage... things just got serious.
I do some maintenance work for the linux kernel dvb and infrared subsystems. I reviewed and accepted some patches from umn.edu addresses. They looked fine to me, however they're all around error handling, which can get pretty tricky with long error paths. What else can I do than revert the lot?
There are another 68 commits which did not revert cleanly, in some cases because they were later fixed up, already reverted, or some other patch has touched those lines of code. This will require further manual work.
We basically at this point assuming bad faith for all UMN patches and reviewing them all before allowing them to stay in. (Or if they get reverted by default, someone else can manually apply them after they go through strict review.)
Fool me once, shame on you, fool me twice....
This is a great statement, they confirm they're aware of the issue, they acknowledge the concerns and they set out their intention to gather the full facts whilst suspending the operation of the research in the meantime. They also acknowledge the systematic way the need to deal with this. I hope their follow up is as thorough but I want to applaud this, it's a good approach.
I also think it's a good response but I think an apology would be in order - perhaps left out because it can be considered an admission of guilt. The way their statement stands they can investigate themselves and determine they did nothing wrong, we'll have to see what they say down the road.
When the issue has gotten actual attention an apology to the kernel mailing list might be appropriate, but as someone who has been apologized to many times it all just becomes meaningless, who cares if you say you’re sorry. I care what you’ll do about it.
Earlier quoted context omitted.
red teaming without approval of the target org is out of fashion, yes.
that helps a bit with regards to understanding why people are so upset about this. but honestly, it seems like valuable research to me. it's unfortunate that it took some time away from busy kernel developers, and it's unfortunate that it ultimately makes the project look worse... ...but isn't that supposed to be part of the promise behind open source? it wouldn't surprise me if i learned that management of private o…
i'll tell you one thing, it has shaken my trust in the oss kernel development model as it operates today, and honestly that seems like maybe a good thing?
how many companies are literally printing money with the linux kernel? can't they throw a few bones at helping beef up code review and security analysis?