The commit message of that commit did not exactly say "Now I am blocking an important security feature" and the change to the sources that did block it was not easy to spot. With the knowledge of the liblzma backdoor the project main maintainer did look more closely to older commits from the bad user and found "whoops, that commit fixing this also contains a small little dot blocking that".

regards Henrik

My Debian machines run Stable, and were not up to the problematic versions. My Manjaro laptops had the patched version the next day. My source platforms pull source using GIT, and the GIT source was never compromised. My deuvan does not run the things that would make the backdoor usable. So far, no problems here.

At least the guy who did that to the kernel immediately reported it, and didn't keep it a secret - seems to me this actor had more malicious intent.


Not directly no - however nobody seem to have caught the fact that commit would not work or compile with said sandboxing feature enabled, so whoever was in charge should have asked why disable it? So by that I guess who ever maintains code going forward when seeing such things should ask "hang on, why does it only compile without said security feature turned on?" And in that case should reject the code in question and demand the code be fixed and that then and there should in my view root out the bad actor - if say the actor had a pattern of such behavior.

From what I understand, the person who was committing the bad code was one of the maintainers. I believe they had social engineered their way to that position over a reasonably long time frame. This was not a rogue commit from a random anonymous person, it's a lot more insidious than that.

1 members found this post helpful.

That's fascinating, but logical really. Questions spring to mind.

We know Governments are hiring coders as hackers like civil servants to do hacking. Now the Jesuits who educated me taught me to think like Machiavelli, as they did. So did the maintainer guy take bribes? Or are there 'bad actor' Government hackers in many OSS projects quietly making commits and working their way up? And how many unknown carefully concealed backdoors are known to some government and ready to use? They will be quickly patched of course, but not necessarily eradicated completely. It sounds like the xz one is being eradicated completely. If I'm right, we may see a few of such bugs before this Election year is out.

It is a relief that Slackware doesn't use Systemd.

1 members found this post helpful.

***off topic****

"Xz format inadequate for long-term archiving"
article written by Antonio Diaz with the support of Lasse Collin
https://www.nongnu.org/lzip/xz_inadequate.html

We would have named this article "please stop doing the idiots with Xz"

Oh yeah, that's an old one. Written by the author of lzip, lzlib, and plzip, so perhaps they could be biased. ;-)

Moving to .tlz is tempting, though.

1 members found this post helpful.

Is the name "Jia Tang" chinese?
If so, are they located in the PRC, or in Taiwan, or in some other community of the chinese diaspora?

If in the PRC, then I doubt this is one lone bad actor, and perhaps much more source code needs to be checked?

Well again I guess hindsight is 20/20; and this is why anyone who is security minded no matter how insignificant should ask questions - I am not a dev; but again I would have still asked "well hang on, WHY do we need to disable a security feature to get this piece of code to work?" The code shouldn't bend over backwards that way, just like a system should bend over backwards for any security reason..

Maybe , does it offer as much compression as xz and decompresses in less time ? Or do you give up some compression ? On the one hand we are in the days of vast data storage, so it is not like it was decades ago where even a megabyte makes a difference, but yea at the same time we don't want to be bloated either and waste too much space...

Why not .zst?

Also under consideration, but support for .tlz is already there in the pkgtools.

But we'll probably stick with .txz, so don't get too excited. ;-)

EDIT: also .tzs would probably be a better three letter suffix.

Darn I was hoping for ZFT

The disadvantage of .tzs as a package suffix is that it would break the current situation of all packages being named *.t?z.

As you say, xz still seems like a rather good compression:

https://linuxreviews.org/Comparison_...ion_Algorithms

For packages we most of all want small size to allow us to have many packages on limited installation media size and second we want quick decompression for fast installations.

regards Henrik

Yes, "Jia Tan" is a name given to some real people in China. However, "Jia Tan" is probably a fake name used by the bad actor.

regards Henrik

Yes, I'm sure my scripts are not the only ones that take advantage of that particular pattern. .tzz would work while maintaining the status quo.

I can work-around anything you decide to go with, but if you can let us know one way or the other then those of us who write package related tools can get ahead of the game should you decide to switch.

2 members found this post helpful.