Live data from Hacker News

Social engineering takeovers of open source projects

openssf.org

231–240 of 379 posts

Re: Social engineering takeovers of open source projects

#231
post #211

Earlier quoted context omitted.

> Has anyone ever bribed an engineer to make a bridge or a water supply less robust Of course, this happens all the time, check the consequences of any earthquake in any corrupt country for the more visible examples

Yeah, for sure. I was mainly thinking about, say, a foreign state actor doing the bribing and not just the usual grift/embezzlement/corruption.

Ah, misunderstood, you mean something like a sneaky sabotage? Hm, don't recall any, the payoff seems to be too small and unpredictable? But I think there were cases of "poisoning" the design of some weapons

Re: Social engineering takeovers of open source projects

#232
post #196
post #155

Earlier quoted context omitted.

I'm sure some security researcher is doing this, but we could easily create a visualization of "who has contributed over time" and identify transitioning of maintainers automatically just from git. This might be worth doing and contributing to a site like bestofjs or libraries.io (I don't really use that one though!)

> who has contributed over time When major security players insist that using GPG is bad, there is no way of knowing if bob@bob.bob is the same account that it was last month or not.

It is not the idea of GPG thats bad. In fact, the idea is great! The implementation of GPG however is quite another thing. Ease of use and user experience are really not that great with GPG. It is difficult to use even for developers. Developers are users too amd so on.

Re: Social engineering takeovers of open source projects

#233

Earlier quoted context omitted.

Why did Eclipse org get so much and Apache org none/less? In my experience, the footprint of Apache exceeds anything else in enterprise programming.

This also struck me as a bit odd.. even more so when you consider that over recent years, eclipse's general usage over time has decreased

Are OpenSFF members using Eclipse sub-projects in the financial services industry? In automotive/embedded, Eclipse hosts the safety-certified OSS ThreadX RTOS (formerly Azure RTOS), which runs on 10B+ devices, https://finance.yahoo.com/news/eclipse-foundation-showcases-...

Re: Social engineering takeovers of open source projects

#234

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception? Great that we'll finally get state-sponsored open-source development :D

[flagged]

It's a multi-layered satirical joke. The 'absurd' aspect is the flipping of 'taking over a library' versus starting one, which is amusing given that the motivations of state-sponsored bad actors are to poison and/or control the hard work of others. They themselves would end up doing the hard work they've undermined. Further satirical layers are added by the prospect of those bad actors producing 'good' software instead of 'evil', and providing funding that they've historically been reluctant to cough up.

Of course, as the old saying goes, explaining a joke is like dissecting a frog: nobody laughs and a frog dies.

Re: Social engineering takeovers of open source projects

#235
post #196

Earlier quoted context omitted.

> who has contributed over time When major security players insist that using GPG is bad, there is no way of knowing if bob@bob.bob is the same account that it was last month or not.

It is not the idea of GPG thats bad. In fact, the idea is great! The implementation of GPG however is quite another thing. Ease of use and user experience are really not that great with GPG. It is difficult to use even for developers. Developers are users too amd so on.

Try uploading a signed package on pypi. Sign it with sequoia instead of GPG if you like.

You'll receive an email asking you to stop uploading signatures.

Re: Social engineering takeovers of open source projects

#236

Earlier quoted context omitted.

US gov has encouraged finance/tech industry to invest in the security of OSS supply chains. OpenSSF members: https://openssf.org/about/members 2021, $10MM, https://openssf.org/press-release/2021/10/13/open-source-sec... > Financial commitments from Premier members include Amazon, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red…

Why did Eclipse org get so much and Apache org none/less? In my experience, the footprint of Apache exceeds anything else in enterprise programming.

Tons of modern and really critical development happens on Eclipse-based environments. Two examples I can think of off the top of my head are

- DBeaver (very widely used to connect to production databases)

- STM32Cube IDE (for embedded development in all sorts of devices)

Re: Social engineering takeovers of open source projects

#237
post #175

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception? Great that we'll finally get state-sponsored open-source development :D

The ideal state is having the world's superpowers all devoting effort to improving open source libraries, but all catching each others' backdoors and at the end of the day improving security for everyone.

Mutually Assured Backdoors

Re: Social engineering takeovers of open source projects

#238
As a (mostly former) OSS maintainer, I don't want to be suspicious of any contributors. I want welcome contributors as co-maintainers.

I don't want to gate-keep specific tasks (such as releasing and updating the website) so that I'm the single point of failure.

It's already hard to enough to get people to contribute more than a README typo fix or maybe a single feature that they need themselves, and get them invested into the project as whole.

Somebody please create an alternative for keeping projects secure that's not based on suspicion and gatekeeping.

Re: Social engineering takeovers of open source projects

#239
post #163

Earlier quoted context omitted.

I've been working on thanks.dev for over two years now & reading this report is disappointing to say the least. Why not spend the time to explain the value XZ Utils created for all the commercial users & what companies can do to better supporting maintainers with hundreds of issues experiencing burnout from their unpaid work? OpenSSF should instead promote FOSS programs like https://frontendmasters.com/blog/how-were-…

On first reading your comment makes a lot of sense, and is certainly logical for maximizing the common good. But unfortunately, companies simply don't work the way you are proposing. The short reason is this "good citizenship is indistinguishable from corruption. Therefore good company governance leans away from both." The somewhat longer answer is that while a "company" might have a lot of money, or might make a lot…

"What companies pay for" is anything they cannot get for free. If the value of an OSS project is mostly in its code, then any license that allows it to be used commercially will mean lots of free-riding.

Re: Social engineering takeovers of open source projects

#240
post #33
post #22

I'm a maintainer (one of many) of an open source project, and this topic has been on my mind a lot lately as I review PRs. I am more suspicious of PRs from new contributors by default now. Of course I keep these suspicions to myself, but besides simply reviewing code for all the regular things, I now ask myself "what sort of sneaky thing could they be doing that appears benign on the surface?"

That's great that you are considering this more now. But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors. If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Compromising…

> If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor.

That's true, but it's also true that a sophisticated and well formed PR is probably genuine too. Hostile PRs are the exception rather than the rule. And if only the high quality PRs are treated with suspicion, then the attackers will tailor their approach to mimic novices. General vigilance is required, but failure is likely because these attacks are so rare that maintainers will grow weary of being paranoid about a threat they've never seen in years of suspicion and let their guard down.

Post reply on HN