Hi, ne 31. 3. 2024 v 1:07 odesílatel Elliott Mitchell <ehem+open...@m5p.com> napsal: > On Sat, Mar 30, 2024 at 10:54:00PM +0100, Oldřich Jedlička wrote: > > > > so 30. 3. 2024 v 16:31 odesílatel Daniel Golle <dan...@makrotopia.org> > > napsal: > > > Hiding a malicious change in a commit is infinitely harder than hiding > > > it in a tarball. > > > > Just a note: The malicious code was part of the tarball because it was > > part of the main Git repository in the first place. Using Git would > > not help in any way in this particular case. Just check [1] together > > with findings [2]. > > > > [1]: https://git.tukaani.org/?p=xz.git;a=shortlog > > [2]: https://boehs.org/node/everything-i-know-about-the-xz-backdoor > > One of the information sources (haha, one can wonder about *any* source > of information): > https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 > > Under "Design": > > >Normally upstream publishes release tarballs that are different than the > >automatically generated ones in GitHub. In these modified tarballs, a > >malicious version of build-to-host.m4 is included to execute a script > >during the build process. > > So the malicious source code was part of all tarballs, but only the > tarballs with the modified `build-to-host.m4` would trigger the malicious > payload. > > So obtaining GitHub's tarballs which came directly from the Git > repository *does* avoid the breach. > > (as does avoiding SystemD, as does not building rpms or .debs, or using > something besides amd64)
Yes, you are right. I wrote it wrong, I just wanted to point out that the crafted files were part of the Git repository already as also stated in https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 There are crafted test files in the tests/ folder within the git repository too. The problem is not using release tarballs or tarballs from GitHub, but trusting that what the author is doing is not malicious. Anyway, I do not want to start discussion about reviews, many eyes watching Git commits and related things, just keep this in mind - the malicious author can do it again and if his plan crosses project boundaries like in this case (xz + systemd), you will not discover it easily. Cheers Oldrich. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel