101–110 of 379 posts
Anyone who has played Eve Online is familiar with this process. Gain membership, become a valued contributor to the corp, then betray it for profit.
If anyone has a few hours free, I'd recommend this documentary about Eve Online - https://www.youtube.com/watch?v=BCSeISYcoyI
Would it be interesting if Github (and others) had a program where they would verify people using the same regulations the banking industry uses for KYC (know your customer)? Optional step for developers to show they are who they say they are?
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…
[flagged]
And by the way, stabbings happen all the time, at least 3 per day. Stabbings hurt a few people, cybersecurity incidents can hurt millions.
Earlier quoted context omitted.
> consider the route of getting "kompromat" on a developer to make them "help" them I suppose that’s an option, but it also introduces an additional risk of exposure for your operation as it doesn’t always work and makes it much more complicated to manage even when it does work.
Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”
The trick is finding the people that can be compromised.
This is only going to get worse with Large Language Models. Let's imagine a somewhat knowledgeable individual, could craft both emails, messages and even commits with a bunch of prompts. Those will relate deeply to the project.
Maybe one day it will happen, but right now LLM-generated persona would likely set off every alarm bell for a lot of people. LLMs have very recognizable style, and it usually falls right into the uncanny valley.
Earlier quoted context omitted.
[flagged]
If someone gets stabbed in the eye, we find out about it. So our statistics on eye-stabbing are probably accurate. We literally have no idea how many xz-style compromises are out there in the wild. We got really lucky with xz - it was only found because the backdoor was sloppy with performance and a microsoft employee got curious. But we have no data on all the times we got unlucky. How many packages in the linux eco…
Earlier quoted context omitted.
[flagged]
We know about the failed attempts, we have no idea about the successful ones, and the ones that are going to be successful in the future.
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…
How about simply paying the maintainers and then getting stuff done like the classical business does.
This is a great write-up. It's a very serious issue. I don't really know if there is any "one solution." I suspect that each project needs to set its own bar, and that any dependency that falls out of maintenance should be removed as quickly as possible (which was good practice, beforehand, but even more important, now). [EDITED TO ADD] I would also think about "scoring" the sensitivity of projects. Things like crypt…
Code: https://github.com/ossf/scorecard
April 2024 ranking of OSS projects by criticality, 100MB CSV: https://commondatastorage.googleapis.com/ossf-criticality-sc...