Just for posterity since I can no longer edit: Libera staff has been firm and unrelenting in their position not to disclose anything whatsoever about the account. I obtained the last point on my own. Libera has made it clear they will not budge on this topic, which I applaud and respect. They were not involved whatsoever in ascertaining a VPN was used, and since that fact makes anything else about the connection information moot, there's nothing else to say about it.

You applaud and respect this?

Either way, I do hope LE will get into this. They better cooperate.

Respect not giving out identifying information on individuals whenever someone asks, no matter what company they work for and what job they do? Yes. I respect this.

I am not LE nor a government official. I did not present a warrant of any kind. I asked in a channel about it. Libera refused to provide information. Libera respecting the privacy of users is of course something I applaud and respect. Why wouldn't I?

I hope you aren’t in control of any customer data.

It's called keeping integrity on not disclosing private info any users from your network, regardless whether they are bad actors.

I respect them for that.

Violating that code is just as bad as the bad actor slipping backdoors.

The alpine patch includes gettext-dev which is likely also exploited as the same authors have been pushing gettext to projects where their changes have been questioned

What do you mean?

Look at the newest commits, do you see anything suspicious:

https://git.alpinelinux.org/aports/log/main/gettext

libunistring could also be affected as that has also been pushed there

> do you see anything suspicious

No.

> libunistring could also be affected as that has also been pushed there

What do you mean by "that"?

Seeing so many commits that are "skip failing test" is a very strong code smell.

Yes, but it is often a sad reality of trying to run projects mainly written for glibc on musl. Not many people write portable C these days.

It's still the wrong way to go about things. Tests are there for a reason, meaning if they fail you should try to understand them to the point where you can fix the problem (broken test or actual bug) instead of just wantonly distabling tests until you get a green light.

FWIW, that's mingw-w64-xz (cross-compiled xz utils) in AUR, not ming-w64 (which would normally refer to the compiler toolchain itself).

Good catch, thanks :)

> EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

Why? Isn't it better to freeze them and let as many people as possible analyze the code?

Good question, though I can imagine they took this action for two reasons:

1. They don't have the ability to freeze repos (i.e. would require some engineering effort to implement it), as I've never seen them do that before.

2. Many distros (and I assume many enterprises) were still linking to the GitHub releases to source the infected tarballs for building. Disabling the repo prevents that.

The infected tarballs and repo are still available elsewhere for researchers to find, too.

They could always archive it. Theoretically (and I mean theoretically only), there's another reason for Microsoft to prevent access to repo: if a nation state was involved, and there've been backdoor conversations to obfuscate the trail.

Archiving the repo doesn't stop the downloads. They would need to rename it in order to prevent distro CI/CD from keeping downloading untrustworthy stuff.

Distros downloading directly from GitHub deserve what they get.

You can still find the source everywhere, if you look for it. Having a fine-looking page distribute vulnerable source code is a much bigger threat.

Maybe one can get the code from here. New commits being added it seems.

https://git.tukaani.org/

The latest commit is interesting (f9cf4c05edd14, "Fix sabotaged Landlock sandbox check").

It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.

Lasse has also started his own documentation on the incident.

https://tukaani.org/xz-backdoor/

Shouldn't they have tests running to ensure that the check works on at least some systems?

What do you mean "tests"?

Have a system were you wxpect the sandboxing to work and have an automated check that it compiles there?

Part of the backdoor was in the tests. The attacker in this case could easily have sabotaged the test as well if a test was required.

If your project becomes complex enough eventually you need tests for the configure step. Even without malicious actors its easy to miss that a compiler or system change broke some check.

Yeah, another of the reasons not to host anything on Github but optional git mirrors, if you don't want your FOSS project to be subject to Microsoft playing a "world police".

Don't agree here. I've only ever seen GitHub do this in extreme circumstances where they were absolutely warranted.

You mean like when they banned all people from wirte access who didn't want to jump to their 2FA bandwagon?

You can find it on archive. Someone archived it last night

Asking this here too: why isn't there an automated A/B or diff match for the tarball contents to match the repo, auto-flag with a warning if that happens? Am I missing something here?

The tarballs mismatching from the git tree is a feature, not a bug. Projects that use submodules may want to include these and projects using autoconf may want to generate and include the configure script.

Here is a longer explainer: https://www.redhat.com/en/blog/what-open-source-upstream

"lol"

> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.

> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.

"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"

> The tarballs mismatching from the git tree is a feature, not a bug.

A feature which allowed the exploit to take place, let's put it that way.

Over here: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...

> The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub.

Multiple suggestions on that thread on how that's a legacy practice that might be outdated, especially in the current climate of cyber threats.

Someone even posted a more thorough gist on what could be done to increase transparency and reduce discrepancies between tarballs and repos: https://gist.github.com/smintrh78/97b5cb4d8332ea4808f25b47c8...

I've posted an earlier WHOWAS of jiatan here: https://news.ycombinator.com/item?id=39868773

It appears to be an RCE, not a public key bypass: https://news.ycombinator.com/item?id=39877312

account is back online https://github.com/JiaT75

Hopefully still locked just visible so people can find and alayze his contributions.