On 24/04/01 08:40AM, orbea wrote: > On Mon, 1 Apr 2024 11:14:15 -0400 > Kenton Groombridge <conc...@gentoo.org> wrote: > > > On 24/03/31 12:13PM, Eddie Chapman wrote: > > > Eli Schwartz wrote: > > > > On 3/29/24 11:07 PM, Eddie Chapman wrote: > > > > > > > >> Given what we've learnt in the last 24hrs about xz utilities, > > > >> you could forgive a paranoid person for seriously considering > > > >> getting rid entirely of them from their systems, especially > > > >> since there are suitable alternatives available. Some might say > > > >> that's a bit extreme, xz-utils will get a thorough audit and it > > > >> will all be fine. But when a malicious actor has been a key > > > >> maintainer of something as complex as a decompression utility > > > >> for years, I'm not sure I could ever trust that codebase again. > > > >> Maybe a complete rewrite will emerge, but I'm personally > > > >> unwilling to continue using xz utils in the meantime for > > > >> uncompressing anything on my systems, even if it is done by an > > > >> unprivileged process. > > > > > > > > > > > > It suffices to downgrade to the version of xz before a social > > > > engineering attack by a malicious actor to gain maintainership of > > > > the xz project. > > > > > > > > Have you been linked to this yet? > > > > https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html > > > > > > > > -- > > > > Eli Schwartz > > > > > > > > > > Yes I saw that yesterday. It only increased my level of concern > > > about the project ten-fold rather than decreased it, particularly > > > because of "he has been helping a lot off-list and is practically a > > > co-maintainer already". > > > > > > > > > > I think it's important to realize that this could have potentially > > happened to any number of various open source projects, not just > > xz-utils. Simply ripping it out and replacing it is not enough to > > prevent these kinds of issues from happening in the future. > > > > There is a major shifting of perspectives as a result of this > > unfortunate compromise. Right now there are serious considerations > > about banning (or otherwise auditing) binary blobs in some projects. > > There are talks about banning the use of older build systems like > > autotools in favor of ones more easily readable and auditable. > > Talk about throwing the baby out with the bathwater... >
Let's not shoot the messenger here. :) I cited this specific example to highlight the shared intent behind positive changes to auditing code not just in the program but also its build system. I didn't mean to imply that this was a great solution. > Its fully possible to write autotools build systems which are simple > and easy to audit. Depending on what blob does it may be far from > trivial or advisable to get rid of it. > > This attack as already has been clearly stated is social, not > technical. If xz-utils used meson or cmake instead it would of not > changed the situation. > > > Ultimately what is happening is a reflection on how we audit critical > > system components and contributions made to them. Change is not going > > to happen over night. > > > > We saw a similar shift with OpenSSL's heartbleed, which ultimately led > > to positive changes in code quality and improving their vulnerability > > reporting process. > > > > There is some good to come of this event, but it's important to > > recognize what went wrong and how open source can improve as a whole. > > > > -- Kenton Groombridge Gentoo Linux Developer, SELinux Project
signature.asc
Description: PGP signature
