On Sat, Mar 30, 2024 at 5:15 PM Bruno Haible wrote:
>
> Eric Gallager wrote:
> > One thing I noticed in the writeup is that part of the way it worked
> > involved a modified copy of gnulib's build-to-host.m4 macro file; ...
> > is if there's anything gnulib can add on
> > its end to ensure that th
Collin Funk wrote:
> This file was .gitignore'd and only contained in the distributed
> tarballs. Given the rest of the situation, the goal was obviously to
> hide this as much as possible. It is annoying that they choose to hide
> it among real, useful Gnulib code.
It was pretty logical that Jia
Eric Gallager wrote:
> One thing I noticed in the writeup is that part of the way it worked
> involved a modified copy of gnulib's build-to-host.m4 macro file; ...
> is if there's anything gnulib can add on
> its end to ensure that the macro actually does what it's supposed to
> do?
Having source
On 3/30/24 10:46 AM, Paul Eggert wrote:
> On 3/29/24 22:04, Eric Gallager wrote:
>> So, one thing I'm wondering, is if there's anything gnulib can add on
>> its end to ensure that the macro actually does what it's supposed to
>> do?
>
> That wouldn't suffice, since the attacker can arrange for gl_
On 3/29/24 22:04, Eric Gallager wrote:
So, one thing I'm wondering, is if there's anything gnulib can add on
its end to ensure that the macro actually does what it's supposed to
do?
That wouldn't suffice, since the attacker can arrange for
gl_BUILD_TO_HOST to do what it's actually supposed to
Hi, I recently read about the major xz backdoor that's been all over
the internet, for example, here:
https://openwall.com/lists/oss-security/2024/03/29/4
One thing I noticed in the writeup is that part of the way it worked
involved a modified copy of gnulib's build-to-host.m4 macro file;
compare t
