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.
Social engineering takeovers of open source projects
231–240 of 379 posts
Re: Social engineering takeovers of open source projects
#232Earlier 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.
Re: Social engineering takeovers of open source projects
#233Earlier 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
Re: Social engineering takeovers of open source projects
#234So 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]
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
#235Earlier 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.
You'll receive an email asking you to stop uploading signatures.
Re: Social engineering takeovers of open source projects
#236Earlier 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.
- 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
#237So 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.
Re: Social engineering takeovers of open source projects
#238I 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
#239Earlier 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…
Re: Social engineering takeovers of open source projects
#240I'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…
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.