Ubuntu 24.04 Beta Delayed Due To XZ Nightmare

[brunosalezze]

No real IT admin jumps on a LTS at release day, you should wait at least one month for the mass adoption bugs to show up and be patched

[tenchrio]

the original comment, if you cared to read before replying, was talking about a month, not a week.

Getting a bit tired of the people not getting it becoming ruder while seemingly being the least informed about Ubuntu releases and their schedule.
Ubuntu 24.04 is set to release on April 25th 2024 (it says so in the article that this very thread is about, what was that about who caring to read what again?), this date was set in October 2023 after 23.10 came out and was way before this news hit. In other words a week later is May 2nd (making 05 applicable), also what currently is delayed is the beta which was supposed to come out April 4th but is now set to April 11th, the date of the original kernel freeze.

And this isn't anything new, with the exception of 17.04 and 5.04 (and I guess 6.06) the 04 versions are released in the latter half of April, 24.04 doesn't even hold the crown being the closest to May, that would be 10.04 being released on April 29th 2010, so a week later there would be May 6th (or 2 days later is May 1st,ooh oh no 2 days delay, the horror).

Both you and DanL are over reacting, minor versions like 25.04 are rarely cared about to begin with, they only get about 9 months of support and the majority of users would stick to the LTS version, their usage numbers are so low they don't even show up on the Steam surveys even in between LTSes (or now despite having 22.10 and 23.04 which are already no longer supported and 23.10 which will see support until July 2024). Loosen up, stop taking it so serious.

[tenchrio]

No real IT admin jumps on a LTS at release day, you should wait at least one month for the mass adoption bugs to show up and be patched

Typically Ubuntu doesn't even give you the upgrade message until after version xx.04.1 is released.
This isn't a coincidence, this is something done by Canonical themselves. And the .1 LTS versions tend to be released about 3 months after.
With 22.04 it even took 4 months (August 11th 2022) before 22.04.1 was released so 20.04 users weren't prompted until 4 months later! My god the absolute madness, wanna know the funny part it was also delayed by a week due to a bug with Snapd but that still placed the original date at the start of august.

[marlock]

tenchrio you're probanly well aware why
DanL is squirming...

with a tiny bit of exaggeration added in, you're basically saying

Tenchrio: "i hope once in my lifetime i get to see a volcano level up an entire town"
DanL: "why would you wish a city to be leveled?!"
TenchRio: "I wouldn't, but if it will happen anyway, I wish I could see it happen"
DanL: "but for you to see it, it must happen, so you're wishing for it! don't!"

I totally get it! I would totally enjoy seeing it too (at the expense of the following Linux Mint distro update being delayed, and I wait for those like a kid waits for presents under the tree at christmas after writing to santa and getting a reply)...

...but it can obviously be unsettling for some people, no point in denying it can... DanL is basically triggered


DanL
Are you a killjoy like this at parties too? Why can't you accept an inch of magical thinking from the other dude yet employ so much magical thinking that you don't let him make his wish or else it might actually come true and someone will get hurt!

Tenchrio is just wishing, not announcing he will sabotage a package to make it happen, LOL... that's what the XZ hacker did, not techrio :P

Yeah, it is silly! Let him be silly!

[sophisticles]

Wait, aren't you the guy who always say companies should close source stuff so their 'numbers go up'? Seems like a psychological obsession with numbers to me...

On a more serious note, however: It's good that Ubuntu is acting out of an abundance of caution. Yes, it might have knock on effects of popping the release a little later, which will bum people out. But any serious industrial user would be unlikely to be planning major migrations immediately anyway - at least I wouldn't want to play early adopter with my infrastructure if it's already working fine on existing LTS releases.

Beyond that though, I feel like the XZ backdoor has been something of a triumph for open-source. We know that nation-state actors work back-doors into closed-source projects from leaks such as Snowden's. We also know that our cyber-infrastructure is vulnerable - we have the word "cyberattack" for a reason. What this attempt has shown though is that the work is scrutinized. Some guy, who isn't an XZ maintainer, was able to identify something was wrong, was able to investigate, to discover the specific cause, and to notify the world. The only reason people are able to panic is because we got to see this happen in real time. We saw the open-source world successfully prevent a exploit, successfully communicate it with urgency, and successfully dissect it.

Is open source accessible to malicious actors? Yes. But it is also, far more uniquely, open to the vast, vast concourse of people who want to make software better and safer too. Can't exactly say the same about the closed source side of the road.

To address a few things:

"nation-state actors work back-doors into closed-source projects"

This is disingenuous because the U.S. has export control laws that have been on the books for decades that dictate what kind of technology can be sold or given to certain countries or people in those countries. In fact there were small businesses that got in trouble for selling the first Playstations to people in restricted countries.

Many countries, primarily European countries have similar restrictions.

I am positive that any Red Hat product sold to anyone outside the U.S. has back doors in it and if you will recall there was the OpenBSD scandal where a developer claimed he had been paid a million dollars by the FBI to install a back door in OpenBSD.

"Some guy, who isn't an XZ maintainer"

He was a Microsoft employee, you know working for that "evil" company that sells proprietary, closed source software.

Wait, aren't you the guy who always say companies should close source stuff so their 'numbers go up'?

Yes, because you can't make money from free, unless you want to depend on donations.

[DanL]

DanL is squirming...

No. No, I'm not and you'd probably be surprised how cool I am at parties.

[marlock]

Is that an invitation? I would actually like to find out... or would I?

Anyway, on a more serious note, I wonder if the Ubuntu and OpenSuse builds are usually done using tarballs... and what they used this time while rebuilding... and if they trust their build pipelines to be uncompromised or scraped it and put those thing back in order from a known good previous state.

[Paradigm Shifter]

Seems a reasonable precaution to take.

A week is not so much time.

[L_A_G]

I must admit that despite being infamously critical of systemd and its functionally monolithic nature, even I couldn't imagine it being used as the bridge between an attack on something non-critical like xz to something genuinely critical like sshd.

Thus, a total rebuild with a rolled back version of xz libs is genuinely the responsible and right thing to do.

The amount of time and effort that went into this is genuinely concerning. Making sure that this only affects debian and derivatives shows that the kind of specificity and restraint that goes into nation state actors' efforts was present. Unaffected builds being genuinely unaffected so that not even a single byte was affected showed some clear technical skill. Being able to convince the disabling of the automated fussing that would've caught this on the affected bit shows some expert social engineering.

Finally, the fact that they built up the persona they used to carry out the malicious commit over several years shows that this was a long running project and most probably isn't the only supply chain attack they're working on or have already successfully carried out. What really worries me is just that. What else they're working on or have already successfully carried out.

[lsatenstein]

All of the top 7 distros (Distrowatch) have applications that make use of embedded ssh. These applications. To be sure that the embedded code does not have the xz virus, or any part of it, are being recompiled. Following retests of the entire test stream, these distros will be releasing new updated versions.
For many, it will be strictly an update for the impacted modules.