181–190 of 482 posts
"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…
The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…
A "good" side effect of this for OSS maintainers going on, is that now any time an entitled user starts being too pushy or too... well, entitled , they can be given a canned response: Are you trying to pull an xz attack on me?
Never allow yourself to be bullied or pressured into action. As a maintainer, the more a contributor or user nags, the less likely I am to oblige.
We've complained about bots in social media for a long time, but how many people in open source discussions are shady manipulative entities?
I wonder, once the attacker gained commit permissions, were they able to rewrite and force push existing commits? In that case rolling back to older commits may not be a solution. If my speculation is correct then the the exact date on which access was granted must then first be known, after that a trusted backup of the repo from before that date is needed. Ideally Lasse Collin would have a daily backup of the repo.…
Force pushes tend to be noticed easily. All it takes is for one external developer to try to pull to see the failure. And it's actually hard to do because you need to comb through the tree to update all the tags that point to the old commits. On top of that it obviously breaks any external references to the commit IDs (e.g. in distro or build configurations), all the way up to cryptographic signatures that might have…
Isn't this part just a few pages of code, if that?
I agree that it will be blindingly obvious for the reasons you list.
"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…
This event should be a wake-up call to businesses everywhere: It's not just a small number of "core" FOSS projects that need their support (funding and assistance!). Before this event who was thinking about a compression library when considering the security of their FOSS dependencies? The scope of "what FOSS needs to be supported and well-funded" just increased by an order of magnitude.
> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware. It's either in source form and reproducable or it's not there.
Wanna know how I know you haven't read into the discussion much?
There are a whole lot of binary test cases in software. Especially when you're dealing with things like file formats and test cases that should specifically fail on bad data of particular types.
Timeline reads like a "pig butchering" or romance scam. Except the goal is not money, but control. Attackers find a vulnerable but critical library in the supply chain. Do a cross check on maintainers or owners of the code (reference social media and other sources to get more information). Execute social engineering attack. Talk to maintainer(s) "off list" to gain rapport. Submit a few non-consequential patches that…
To me this is the polar opposite of pig butchering. This was a targeted and unromantic attack, unrelated to investing or cryptocurrency, the original maintainer was not "fattened like a hog" in any way, if anything he was bullied and abused into submission.
This seems very difficult to defend against. What is a project with a single burnt-out committer to do?
Check the GitHub profile of anybody that commits. Is there a photo of the person? Can you see a commit history and repos that help validate who they seem to be. In this instance, noticing the people emailing to pressure you have fake looking names that start with adjacent letters and the same domain name. Be more paranoid.
Does that even matter these days?
Especially if we're talking nation state level stuff convincing histories are not hard to create to deflect casual observers.
>Be more paranoid.
Most people in OSS just want to write some code to do something, not defend the world against evil.
Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.
The Jia Tan character was never rude. If you make rudeness the thing that throws a red flag, then ‘nice’ fake accounts will bubble up to do the pressuring.