Eddie Chapman posted on Tue, 2 Apr 2024 20:32:41 +0100 as excerpted: > Yes, I have no issue with the format at all, just with the xz utils > project.
FWIW, feel free to do that bug-fix or package-bump if you'd rather instead of reading this long thing! I won't complain! =:^) IMO... The thing is, the actual problem isn't the xz-utils project. Roll the dice. The attack could have happened to any one (or more) of a number of projects... and a few years ago, before the Linux Foundation sponsored a project to coordinate helping out various one-person upstreams with security sponsorships and etc, it could have been quite a few more. xz- utils just happens to be the one one with the bad luck to be attacked and where we actually discovered the attack... that wasn't yet covered by the LF security support program as its "core Linux infra" connection via systemd is relatively new and only developed more or less in parallel with that program, so it had until now fallen through the cracks. Now that the attack on xz-utils has been exposed, we've already rolled back to before the attacker got involved. So we see the (symptomatic/ surface) problem there and have already addressed it, tho as I said the real problem isn't xz-utils at all. Sure we could go to more extreme lengths to allow xz-utils to be taken out of the picture, but what would that do? We've already reverted to before the attacker was in the picture, and it's simply impossible to alternative-force /all/ of the currently at-risk packages, some of which might already be compromised only we don't know it yet, actually putting them in a WORSE position, or there'd likely not be enough left to make a working distro! In fact, the attacker (or one of the near-zero-history posters that urged his xz-utils releases be accepted, I don't remember the specifics as I read a lot of articles and a lot of followup discussion over the weekend) had apparently also made a commit to libarchive, tho it's quite possible it was of the "gain their trust with an innocent commit first" kind or that they abandoned that effort when the xz-utils effort appeared to be working better. Of course by the time I read about that over the weekend people were already scouring that and looking for others. Are we going to kill libarchive too, when it's just one commit and it's now known and scoured? How many other packages are going to have low- history/bad-history commits that look iffy now? How may of them can we really find alternatives for that don't have the same or worse problems? So we can't throw the baby out with the bath-water, which is where we'd end up if we took the same approach for all the packages in a similar situation if not worse because we can't fix what we haven't discovered yet! Rather, the (IMO) more reasonable approach is what people are already doing, addressing the systemic issues. One of these systemic issues is that for not until now examined historical reasons, it's considered reasonable for release tarballs to differ from the tarball created from the pure repo release-tag checkout. In some cases that's at least presently needed due to the way autotools and traditional release processes work, but that's being reexamined now, with some packages already able to switch to release-tag-corresponding tarballs, while others can't yet, but are high-priority examining changes in procedure and/or release tooling so they can. So that's likely to change for many packages within a release or two, and people will be pressuring the ones that don't and/or considering switching to alternatives. *That* is actually a (IMO) /reasonable/ alternative-consideration -- over the next months, examine packages that aren't already switching to tag- corresponding release tarballs and consider alternatives to /them/! Another of the systemic issues is the number of Linux-core-infra packages with a "bus-factor" of one or even two (consider that until this happened, xz-utils seemed to now have two, nobody realizing the one was actually an attacker). Now that xz-utils had this known attack AND it's now known to be core-critical (for distros with that systemd integration... which of course includes both two big names and two enterprise products with real money behind them), I'm sure the original author has all sorts of offers of help, both for simple maintenance, and scouring for any other security issues. We really shouldn't have to worry about it any longer. And I've already mentioned the LF security help program which helps for many. But there's likely a dozen (more?) other packages that are either relatively newly core-integrated or that have fallen through the cracks until now for other reasons. There's going to be real-money efforts to find these and add them to the security-help list now, because there's real-money products at stake! Yet another issue, once tarballs can be verified against release tags, is that a lot of distro maintainers don't actually verify the code changes. Some simply don't have the necesary skills. Others have the skills, but still don't verify, because the tooling isn't there to make it fast/simple enough for them and there's always more packages to bump then time to actually do it. Now, due to the xz-utils attack revealing the problem, there's already community efforts to improve the tooling to make it easier for distro maintainers to not only look at the commit logs, but go a bit deeper than that and better show the changed code. And many maintainers are redoubling their efforts to make routine at least minimal change-audits with the existing tooling in the mean time. Helping with any of these three would certainly be reasonable. But demanding a *LOT* of work to alternative-force an already attack-reverted package, when we actually KNOW about that one, it's reverted to pre-attack and there's likely to be no more mischief there /because/ everybody's looking at it now, when it could have been any of a number of packages, some of which might already be compromised and we just didn't happen to find it, IMO really doesn't make much sense. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
