Christoph Anton Mitterer dixit:
>So Thorsten, in case you or someone else is aware of any [intermediate]
>results from these task forces ([9[) it would be nice to hear about
>them or better even in form of some "official" statement from Debian.
JFTR I’m not involved in those myself.
bye,
Hey.
On Sun, 2024-03-31 at 01:46 +, Thorsten Glaser wrote:
> Yes, a multi-team task force is working on it and will inform users
> once it is known how to proceed, inclusing how much to throw away
> and rebuild.
Kindly wanted to ask whether anything has come out meanwhile of that?
I've
On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno
wrote:
> On 2024-03-29 16:25, Joey Hess wrote:
> > I'd suggest reverting to 5.3.1. Bearing in mind that there were security
> > fixes after that point for ZDI-CAN-16587 that would need to be
reapplied.
>
> Note that reverted to such an old version
On 2024-04-02 14:34:20 [+0200], Guillem Jover wrote:
> (Please do not take this mail as endorsing any specific action, just
> wanted to clarify/correct the above.)
Right, same here. The 5.4.x series has threaded decompression which I
would like to keep. The 5.6.x series has branchless
Joey Hess dixit:
>--- orig/dpkg-1.22.6/debian/control2024-03-02 21:30:15.0 -0400
>+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400
> # Version needed for multi-threaded decompressor support.
>- liblzma-dev (>= 5.4.0),
>+ liblzmaunscathed-dev,
The comment probably
Guillem Jover wrote:
> dpkg should be able to use an old liblzma w/o multi-threaded compressor
> or decompressor support
Ah you're right. configure did find the library, but I'd missed updating
some ifdefs. Attached updated dpkg patch which does build with the
shared library and works.
--
see
Hi!
On Sat, 2024-03-30 at 14:16:52 -0400, Joey Hess wrote:
> My git repository is here (note all my commits are gpg signed):
> https://git.joeyh.name/index.cgi/xz-unscathed/
> My build of dpkg ended up not being linked to a lzma library at all,
> because liblzmaunscathed is too old to support
> The situation is being analysed by a cross-team taskforce,
> please let them do the already-stressing job ☻
Sorry, didn't see that before sending my previous message.
I'll leave it to you guys.
--
see shy jo
signature.asc
Description: PGP signature
Since there's been some discussion about versions, the version in my
xz-unscathed git repository is the same as xz 5.3.2alpha, with the
addition of a fix for CVE-2022-1271 that did not make it into that
version. (It was fixed in 5.2.6, but 5.3.2alpha was diverged from
5.2.5. Jia Tan was involved
Christoph Anton Mitterer dixit:
>Is anyone on the Debian side trying to figure out how far we've been
>practically affected?
Yes, a multi-team task force is working on it and will inform users
once it is known how to proceed, inclusing how much to throw away
and rebuild.
bye,
//mirabilos
--
Pierre Ynard dixit:
>version into the Debian archive, as seen in #1067708. To quote Thorsten
>from that thread:
>
>> Very much *not* a fan of NMUs doing large changes such as
>> new upstream versions.
>
>I can't say why exactly he would not be a fan, but with hindsight that
>was an interesting
Christoph Anton Mitterer dixit:
>Can we be confidently sure that going back to 5.4.5 is enough?
No.
>The last one, still from Lasse Collin seems to be 5.4.1:
In this bugreport, we’re discussing going back to before any
contributions by the adversary. To see whether it’s an option
at all (and
One more thing:
Is anyone on the Debian side trying to figure out how far we've been
practically affected?
I mean let's assume we're "lucky", and the backdoor is only in
5.6.0/5.6.1... and that none of the adversary's earlier commits
introduced any serious holes[0] which wouldn't be known yet.
On Sun, Mar 31, 2024 at 01:16:07AM +0100, Christoph Anton Mitterer wrote:
> The last one, still from Lasse Collin seems to be 5.4.1:
> https://git.tukaani.org/?p=xz.git;a=tag;h=f52502e78bf84f516a739e8d8a1357f27eeea75f
There are commits from Jia before that, and some that are authored by
Lasse but
Hey.
Can we be confidently sure that going back to 5.4.5 is enough?
At least the git tag for that seems to be still signed by the
adversary:
https://git.tukaani.org/?p=xz.git;a=tag;h=9e4835399118b98954f110f76af2a0d504d2f531
The last one, still from Lasse Collin seems to be 5.4.1:
I have prepared a git repository that is a fork of xz from the point I
identified before the attacker(s) did anything to it. In my fork, I have
renamed liblzma to liblzmaunscathed. That allows it to be installed
alongside current dpkg without breaking dpkg with an old version of
liblzma.
My git
> On 2024-03-30, Guillem Jover wrote:
> On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote:
>> Subject: Re: Bug#1068024: Or remove xz altogether?
>> Maybe the people who criticized xz back in the day for being an amateur
>> project implementing a defective file format were
Aurelien Jarno wrote:
> Note that reverted to such an old version will break packages that use
> new symbols introduced since then. From a quick look, this is at least:
> - dpkg
> - erofs-utils
> - kmod
>
> Having dpkg in that list means that such downgrade has to be planned
> carefully.
I agree
> Might be easier overall to spend that effort on a hard switch to zstd
> instead.
Good point. Another question that we'll probably have to ask anyway
is, what is the future of xz-utils going to be now? Regarding its
maintainership as well, both upstream and in Debian?
>From what I understand,
On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno
wrote:
> Having dpkg in that list means that such downgrade has to be planned
> carefully.
Might be easier overall to spend that effort on a hard switch to zstd
instead.
mfG mow
Aurelien Jarno dixit:
>Having dpkg in that list means that such downgrade has to be planned
>carefully.
Right. Not an argument against, though.
Instead, this is a very good idea.
What symbols are new? Can we somehow stub them, or at least where
those are used? Or change the soname, so that the
On 2024-03-29 16:25, Joey Hess wrote:
> I'd suggest reverting to 5.3.1. Bearing in mind that there were security
> fixes after that point for ZDI-CAN-16587 that would need to be reapplied.
Note that reverted to such an old version will break packages that use
new symbols introduced since then.
Package: xz-utils
Version: 5.6.1+really5.4.5-1
Severity: important
Tags: security
I count a minimum of 750 commits or contributions to xz by Jia Tan, who
backdoored it.
This includes all 700 commits made after they merged a pull request in Jan 7
2023, at which point they appear to have already
23 matches
Mail list logo
