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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)