291–300 of 379 posts
Earlier quoted context omitted.
Maybe not so impossible. Start with making a list of projects that are everywhere. Inside every Linux distribution, inside every react/angular/vue/etc project, … Then check which companies support those projects with active development, and calculate a rating. Are the companies located inside democracies or are they mostly from china or Russia? It’s probably not that many packages in the end. A few thousand high impa…
The list you speak of already exists — it is the package registries of Debian/Ubuntu, RHEL, etc. What about American companies using mainland China developers to drive their (well known) open source projects with crappy code? Who’s to blame? We’re currently smoking at the gas station and things haven’t blown up yet…
Earlier quoted context omitted.
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-...
Ahhh, I was thinking they were just funding the IDE.
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
> Great that we'll finally get state-sponsored open-source development :D Suspicions are very old: "Report of FBI back door roils OpenBSD community" (2010)- https://www.cnet.com/news/privacy/report-of-fbi-back-door-ro...
Earlier quoted context omitted.
You can always use this line because you can never prove something doesn't exist. Go find evidence. It's been over a month.
Your choice of language in your comments (in this thread, not in general) isn’t bolstering your argument. Why not be curious rather than just dismissive? This seems to be people just talking past each other at this point. There have been a lot of changes in the last ~five years that point in the direction of supply chain security being at greater risk. Evidence comes in many forms. The relevance of evidence depends o…
Yeah, you're probably not wrong. I've had this argument a few times now, and it's the same dismissive "we don't know what we don't know" every time. Well, you can say that for everything and given the complexities of the xz attack that seems a bit unlikely to me, which is then again countered with "but we don't know!!11"
"Every contributor is dangerous" is spectacularly toxic type of attitude. I've already seen random people be made a target and even had their employers contacted over this before they even had a chance to explain(!!) To say nothing of "there are many ways to compromise existing maintainers. Compromising people is the core competency of intelligence, happens all the time" – so great, now I'm also potentially dangerous after spending untold hours and money over the last 20 years because I could be compromised. Great.
This was never a nuanced conversation about risk management to start with. This is not the type of community I've worked for all this time. "Let's use some common-sense tech so this isn't that easy". Sure, let's talk about that. "Let's treat every volunteer involved as potentially hostile and compromised after we've seen a single incident"? Yeah, nah.
Earlier quoted context omitted.
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…
It added a "kinda useful but not really needed" feature and removed an unrelated line of code, thereby introducing a minor security vulnerability.
My suspicion is that these low quality PRs are similar to the intentional typos in spam emails: Identify projects/ maintainers who are sloppy/ gullible enough and start getting a foot in the door.
Earlier quoted context omitted.
>If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Unforuntately it's easy to sandbag being dumb. Just because someone submits a PR defining constants for 0-999 does not mean they're actually bad at programming.
How incredibly wasteful. You can form most useful numbers with just ten singe-digit constants, some casting, and string concatenation.
Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it. Those changes of maintainers need to be synced to package distribution sites like npm.js or Debian packages and put in context with versions/releases. In Europe this was introduced for banks after the banking crisis. If a bank does any organizational change, a report is sent…
It might be that no open source contributions I've made are things people care about, but I'm not spending one second of my time for free updating databases so multi-billion dollar companies can feel safer.
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
If it's an everybody uses it solution it will eventually be reimplemented as a part of the environment, like the browser or the kernel. The lifetime is limited and linking to a library like that wouldn't mesh very well there.