Live data from Hacker News

Open letter from researchers involved in the “hypocrite commit” debacle

lore.kernel.org

271–280 of 384 posts

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#271
post #264

Earlier quoted context omitted.

> you can hire there lies the difference, duh.

And what about the hundreds of NPM dependencies in VS Code no one reviews? Or the the thousands of brew packages that are blindly merged unsigned by 800 people with access? Who pays to give a white hat as much freedom to find supply chain attack vectors here? Who gets consent from every random student whose code, if compromised, would compromise every major company? We have created a massive mess, and I don't know th…

holy moving the goalpost batman, slow down.

> We are going to need unpaid volunteers, and a lot of them.

that's absolutely orthogonal to the question at hand, it's not a matter of paid or unpaid, neither being volunteer or not: it's a matter of consent.

if you don't sought consent beforehand either via a contract relationship or a sponsored bug hunt program or the likes, you're a racketeer, not a white hat, and you should (and will) be treated as such.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#272

This apology fails from the 5th word: "We sincerely apologize for any harm..." While there are other requirements, a sincere apology cannot in any way entertain doubt about the fact that there WAS harm. Truly acknowledging the harm done is foundational to a real apology, and most of us (myself included) end up sneaking in weasel words or phrases like this. Psychologically, its nice for the apologizer, since it allows…

I too bristled at the word “any” for an apology.

I would have listed the specific harms in a concise manner instead.

Maybe save that word “any” for the end, maybe and only as a future tense of profusely avoidance of future harm.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#273

Earlier quoted context omitted.

ESL here. How correct is it to use ’any harm’ to mean ‘all harm’.

That depends on the sentence context.[1] As used here it is fully correct; "we sincerely apologize for all harm our research group did" would be highly anomalous, whereas the phrasing they actually used is conventional. "We sincerely apologize for all the harm our research group did" would be a little less unnatural than "...for all harm...", but it's still an unusual choice of wording that ends up sounding like you…

How about "we apologize for the harm"?

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#274
post #29

Earlier quoted context omitted.

Their opening statement has the most classic of all non-apology tactics: "We're sorry for any harm we caused". Maybe this wasn't their intent, but this is one of the oldest "say the words without having to mean anything" tactics in the book. It's like telling your partner "I'm sorry if I hurt you". No, you hurt them. Apologize for hurting them.

An apology should be for actions taken, not for how the other party felt about it. Acknowledging those feelings is important, but taking credit for those feelings takes agency away from the other person.

I don’t think that really makes sense. Often in a personal relationship the “action taken” will be innocuous considered in itself. But you may have done it knowing full well that it would hurt the other person’s feelings. In a case where the person’s feelings are totally irrational and you had a strong independent justification for taking the action, it does get more complicated. In general, though, I think it’s a huge mistake to assume that you should never apologize for hurting someone’s feelings.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#275
post #261

Earlier quoted context omitted.

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because no…

This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do t…

> even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade

So...contrary to what you suggest in your first paragraph, all you need to do is send out a handful of warning emails at the appropriate juncture. What’s the problem? For sure you shouldn’t be submitting malicious code to a project without forewarning. That's just a basic ethical no-no. Even if you were right that this kind of unethical research somehow had beneficial results, the ends wouldn't justify the means.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#276

Earlier quoted context omitted.

>I am a Red Teamer and work with companies OK, how do you test SocEng vectors? Do you obtain consent and coordinate with every employee that might be targeted to receive your e-mail? >You also study submitting from yandex, gmail, .cn and other email addresses No, the point was submitting from a known and respectable entity, which might affect the level of scrutiny. They weren't testing a whole patching process, but a…

You don’t. You work with the leadership & security team. Any employee that clicks your phishing email gets an extra dose of security training. Those that forward the email to abuse@corp.com get a nice compliment

Just clicking the link is enough to fail? No need to enter private info or execute downloaded files? Either your phising emails are badly crafted or you expect employees to see the future.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#277
The only good thing of this whole ordeal is that patches scrutiny and security awareness will improve for some time; but I despise the experiment and anyways believe that it will not lead to some organic improvement of the review process.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#278
post #261

Earlier quoted context omitted.

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because no…

This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do t…

> Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this.

That's not what happened. Nobody is asking (or is expected to ask) when they look for vulnerabilities. The researchers were trying to introduce vulnerabilities. Had they only looked at the tools that maintainers use and given those a good shake to see whether an attack vector is lurking there, everybody would have been happy.

> IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects.

The likely consequence of that would be maintainers shutting down public contributions because nobody has time to deal with automated submissions from scripts that are bounty hunting.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#279

Earlier quoted context omitted.

You don’t. You work with the leadership & security team. Any employee that clicks your phishing email gets an extra dose of security training. Those that forward the email to abuse@corp.com get a nice compliment

Just clicking the link is enough to fail? No need to enter private info or execute downloaded files? Either your phising emails are badly crafted or you expect employees to see the future.

Agreed. This is something that made me very annoyed when they did it to us. I know exactly what I'm doing, I know that you can't infect a computer from opening a link unless the attacker possesses a new browser 0-day, and expecting your average employee to worry about new browser 0-days is ridiculous.

If it were an obvious phishing URL, like a variation on the company domain, then fine (maybe). But it wasn't.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#280
post #267

Earlier quoted context omitted.

FWIW I completely agree with you but I see no way out. The Linux kernel project needs and deserves the best security methods but (a) likely can't afford the people and (b) bringing more money aboard might draw unmotivated people only after the paycheck which could objectively deteriorate the project's code quality. Dual cryptographic signoff still doesn't address any social issues (or I'm grossly misunderstanding it…

Most projects have virtually no accountability at all. Hundreds of people have blind push access to brew. Almost no one signs code. One bad commit and you backdoor every company in silicon valley that blindly executes the unsigned code from the brew repo. Pick a favorite Linux distro. All but a handful work the same way. Right now an low skill level malicious party just needs to phish one of the ~90% of maintainers t…

I agree it's insane but this is what the market optimizes for.

I pushed for more security and better practices until I was fired from 3 companies. It's quite obvious that business only cares about PR; if a big security incident happens they are more interested in how to reduce liability and not how to prevent the problem in the first place [the next time around].

Until programmers become an elite clique with a huge barrier to entry and our own independent income -- completely disconnected from the interests of those who want to use our services -- then we have our hands tied and are at the mercy of the paycheck and its innate conflicts of interest with good craftsmanship.

Post reply on HN