841–850 of 1001 posts
Earlier quoted context omitted.
The same authors have also contributed to Zstd
details please? I do not see any such contributions to https://github.com/facebook/zstd
Jia had a zstd fork on github, but when things kicked off, it appears they may have sanitized the fork.
Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?
The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.
The fundamental problem here was a violation of chain of trust. Open source is only about the source being open. But if users are just downloading blobs with prebuilt binaries or even _pre-generated scripts_ that aren't in the original source, there is nothing a less-obscure build system will save you from as you are putting your entire security on the chain of trust being maintained.
Wait, I'm on mobile. Did this partially slip by because of the ABSURD PRACTICE of publishing release.tarballs that do not 1:1 correspond with source? Let me guess, autotools? I want to rage shit post but I guess I'll wait for confirmation first. EDIT: YUP, AT LEAST PARTIALLY. Fucking god damn autotools.
Earlier quoted context omitted.
Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.
PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get: xz --version Homebrew has already taken action, a `brew upgrade` will downgrade back to the last known good version.
I understand it's unlikely, but is there anything I can do to check if the backdoor was used? Also any other steps I should take after "brew upgrade"?
This is why we never upgrade software versions. I’ve been asked by our customers why we use such an old AMI version. This is why.
It only took 6 days for it to be found and fixed.
Earlier quoted context omitted.
Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.
PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get: xz --version Homebrew has already taken action, a `brew upgrade` will downgrade back to the last known good version.
Earlier quoted context omitted.
A big part of the problem is all the tooling around git (like the default github UI) which hides diffs for binary files like these pseudo-"test" files. Makes them an ideal place to hide exploit data since comparatively few people would bother opening a hex editor manually.
testdata should not be on the same machine as the build is done. testdata (and tests generally) aren't as well audited, and therefore shouldn't be allowed to leak into the finished product. Sure - you want to test stuff, but that can be done with a special "test build" in it's own VM.
This incident shows that killing the autoconf goop is long overdue.