Originally posted by aviallon
View Post
Announcement
Collapse
No announcement yet.
Updated XZ Code Lands In Linux 6.12
Collapse
X
-
Aww, people. The xz in kernel was very likely from before the evil additions. Moreover, it the very backdoor relied also on other funcitonality iirc. Besides, the hole is closed upstream and this is now double- and triple-reviewed stuff that enters the kernel. It is one of multiple methods to compress kernel image or modules. Feel free to use a different one.
And one should take into account that the mess happened because a developer (who did a good job) was so overworked, that he was just happy that someone stepped up and offered help, which was - sadly - a nicely tailored social engineering attack.
So I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.Stop TCPA, stupid software patents and corrupt politicians!
- Likes 5
Comment
-
Originally posted by Adarion View PostAww, people. The xz in kernel was very likely from before the evil additions.
Originally posted by Adarion View Postand this is now double- and triple-reviewed stuff that enters the kernel.
Originally posted by Adarion View PostSo I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.
I'm totally unfamiliar with compression methods, that's why I'm asking: why xz? Is it so good at compression ratio and at decompression time? Because these are the most important metrics. Compression time doensn't really matter, because it happens once.
Comment
-
Originally posted by User29 View PostI'm totally unfamiliar with compression methods, that's why I'm asking: why xz? Is it so good at compression ratio and at decompression time? Because these are the most important metrics. Compression time doensn't really matter, because it happens once.
But yeah you guys completely forget the kernel also needs to be able to decompress squashfs xz compressed images since they can be mounted.
Comment
-
Originally posted by User29 View Post
Ok, I didn't know this, I thought the code is the same.
Code review: this was true ~20 years ago, but now? The code is just enormous. Just check the recent large folio issue (affected XFS and probably more). The commits were reviewed, weren't they? And a logical bug slipped in which was later fixed accidentally by another commit. Noone noticed it until someone reported it and volunteered for testing.
- Likes 1
Comment
-
Originally posted by Adarion View PostSo I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.
Comment
-
Originally posted by nanonyme View PostRight, it does little merit to try to security shame xz out of kernel based on the incident in userbase. What is a relevant topic is whether xz overall still makes sense as a compression now with zstd being present as well.
Comment
-
Comment