Also does qemu link to libarchive? The original analysis wasn't a full reverse engineer of the payload so we don't know if it only affects sshd.
On Sat, 30 Mar 2024, 07:01 Daniel P. Berrangé, <berra...@redhat.com> wrote: > On Fri, Mar 29, 2024 at 06:59:30PM +0100, Paolo Bonzini wrote: > > For more info, see > > > https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlx...@awork3.anarazel.de/ > > but, essentially, xz was backdoored and it seems like upstream was > directly > > responsible for this. > > > > Based on this, should we switch our distribution from bz2+xz to bz2+zstd > or > > bz2+lzip? > > Based on the attack vector of pre-loading git with an exploit, but then > modifying the tarball to activate it, there's a bigger question of whether > users should really trust manually created tarballs at all ? You don't > anything about either the tarball creator, or the state of creators' > machine, > even if it is signed. How can you trust that its contents is a faithful > representation of the tagged release from git it claims to be? > > This issue could prompt a push towards distros only handling tarballs > directly auto-generated from a git tag, in a reliably reproducible manner. > > Obviously you couldn't actually trust the upstream maintainer in this > case, but at least if you're using a reproducible git tarball you can > verify every link in the chain right through each git commit, and don't > have this manual tarball whose contents need to be to picked apart. > > TL;DR; I think we should consider our tarball distribution options, but > lets wait for the dust to settle and not rush into decisions. > > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > >
