Tomas Volf wrote:
On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:
With a reproducible build system, multiple maintainers can "make dist"
and compare the output to cross-check for erroneous / malicious dist
environments. Multiple signatures should be harder to compromise,
assuming each is
Eric Gallager wrote:
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote:
dherr...@tentpost.com wrote:
[...]
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate that data. In this case, that
binary data was used to smuggle
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate
On 1/4/24 06:00, Eric Gallager wrote:
So, `aclocal` has a flag to control this behavior: specifically, its
`--install` flag. Right now I don't see `aclocal` mentioned in the GNU
Coding Standards at all. Should they be updated to include a
recommendation as to whether it's better to put
On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:
> > > With a reproducible build system, multiple maintainers can "make dist"
> > > and compare the output to cross-check for erroneous / malicious dist
> > > environments. Multiple signatures should be harder to compromise,
> > > assuming each
On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery wrote:
>
> Eric Gallager writes:
>
> > Well, other people besides the maintainers can also run `make dist` and
> > `make distcheck`. My idea was to get end-users in the habit of running
> > `make distcheck` themselves before installing stuff. And if
Eric Gallager writes:
> Well, other people besides the maintainers can also run `make dist` and
> `make distcheck`. My idea was to get end-users in the habit of running
> `make distcheck` themselves before installing stuff. And if that's too
> much to ask of end users, I'd also point out that
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote:
>
> dherr...@tentpost.com wrote:
> > On 2024-03-30 18:25, Bruno Haible wrote:
> >> Eric Gallager wrote:
> >>>
> >>> Hm, so should automake's `distcheck` target be updated to perform
> >>> these checks as well, then?
> >>
> >> The first
> [...]
>> I agree that distcheck is good but not a cure all. Any static
>> system can be attacked when there is motive, and unit tests are
>> easily gamed.
>
> The issue seems to be releases containing binary data for unit tests,
> instead of source or scripts to generate that data. In this
Bluntly, I don't think it would help with security. The attacker would
just have to disable or adjust the distcheck target to seemingly pass.
Yeah, it should be noted that the way the backdoor got into the code
was by the _co-maintainer_ -- distcheck or not, would not have
mattered,
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
There is a bit more to it all than just this -- the maintainer wasn't
responsible (Lasse Collin), the
I think it is pretty clear by now. [1][2][3]
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[2] https://news.ycombinator.com/item?id=39865810
[3] https://www.youtube.com/watch?v=Kw8MCN5uJPg
There is not much one can do when a maintainer with signing/release
power does
Bob Friesenhahn wrote:
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[2]
On 3/30/24 19:00, Alexandre Oliva wrote:
Bluntly, I don't think it would help with security. The attacker would
just have to disable or adjust the distcheck target to seemingly pass.
Relying on something in a code repository to tell whether the repository
is secure is akin to tying a dog with
dherr...@tentpost.com wrote:
On 2024-03-30 18:25, Bruno Haible wrote:
Eric Gallager wrote:
Hm, so should automake's `distcheck` target be updated to perform
these checks as well, then?
The first mentioned check can not be automated. ...
The second mentioned check could be done by the
Eric Gallager wrote:
Specifically, what caught my attention was how the release tarball
containing the backdoor didn't match the history of the project in its
git repository. That made me think about automake's `distcheck`
target, whose entire purpose is to make it easier to verify that a
16 matches
Mail list logo
