[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I'm currently looking at adding support for this to
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> While it does not /prevent/ cracks, there is something we can ensure
> that
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> To avoid false positives if this test is used, we might want to add a
> rule
Bruno Haible wrote:
Richard Stallman commented on Jacob Bachmeyer's idea:
> > Another related check that /would/ have caught this attempt would be
> > comparing the aclocal m4 files in a release against their (meta)upstream
> > sources before building a package. This is something
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
[...]
When considering any such change, we still should
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Can anyone think of a feasible way to prevent this sort of attack?
> A
Bruno Haible writes:
> Richard Stallman commented on Jacob Bachmeyer's idea:
>> > > Another related check that /would/ have caught this attempt would be
>> > > comparing the aclocal m4 files in a release against their
>> (meta)upstream
>> > > sources before building a package. This is
Richard Stallman commented on Jacob Bachmeyer's idea:
> > > Another related check that /would/ have caught this attempt would be
> > > comparing the aclocal m4 files in a release against their
> (meta)upstream
> > > sources before building a package. This is something distribution
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Now for a bit of speculation. I speculate that a cracker was careless
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I would like to clarify that my purpose in starting this thread wasn't
> so
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Another related check that /would/ have caught this attempt would be
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively trivial attack
Eric Blake wrote:
[adding in coreutils, for some history]
[...]
At any rate, it is now obvious (in hindsight) that zstd has a much
larger development team than xz, which may alter the ability of zstd
being backdoored in the same way that xz was, merely by social
engineering of a lone
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The issue seems to be releases containing binary data
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What would be helpful is if `make dist' would
On Tue, Apr 2, 2024 at 6:05 PM Karl Berry wrote:
>
> I'm also wondering whether the GNU system should recommend using zstd
> instead of or in addition to xz for compression purposes.
>
> I'm not sure GNU explicitly recommends anything. Although the tarball
> examples in standards.texi and
On 4/2/24 16:42, Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.
I'm not sure GNU explicitly recommends anything. Although the tarball
examples in standards.texi and maintain.texi all use gz, I don't think
even gz is
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes. Automake
gained support for dist-zstd back in 2019 [1], but I'm not sure how
many projects are using it yet.
[1]
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The issue seems to be releases containing binary data for unit tests,
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively trivial attack vector
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> There is not much one can do when a maintainer with signing/release
> power
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> There is not much one can do when a maintainer with signing/release
> power
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What would be helpful is if `make dist' would guarantee to produce the same
>
[adding in coreutils, for some history]
On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote:
> I was recently reading about the backdoor announced in xz-utils the
> other day, and one of the things that caught my attention was how
> (ab)use of the GNU build system played a role in
Jacob Bachmeyer wrote:
> Another related check that /would/ have caught this attempt would be
> comparing the aclocal m4 files in a release against their (meta)upstream
> sources before building a package. This is something distribution
> maintainers could do without cooperation from upstream.
> Jose E. Marchesi wrote:
>>> 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
Eric Gallager wrote:
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
Russ Allbery wrote:
[...] I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in the form of added files.
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
>
> Russ Allbery wrote:
> > [...]
> >
> > There is extensive ongoing discussion of this on debian-devel. There's no
> > real consensus in that discussion, but I think one useful principle that's
> > emerged that doesn't disrupt the world
Jacob Bachmeyer writes:
> The m4 files were not checked into the repository, instead being added
> (presumably by running autogen.sh with a rigged local m4 file
> collection) while preparing the release.
Ah, yes, I think you are correct. For some reason I thought the
legitimate
Zack Weinberg wrote:
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
"Zack Weinberg" writes:
It might indeed be worth thinking about ways to minimize the
difference between the tarball "make dist" produces and the tarball
"git archive" produces, starting from the same clean git
Russ Allbery wrote:
[...]
There is extensive ongoing discussion of this on debian-devel. There's no
real consensus in that discussion, but I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in
Zack Weinberg wrote:
[...] but I do think there's a valid point here: the malicious xz
maintainer *might* have been caught earlier if they had committed the
build-to-host.m4 modification to xz's VCS.
That would require someone to notice that xz.git has a build-to-host.m4
that does not exist
Jose E. Marchesi wrote:
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
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in the "Standard
>
Eric Gallager wrote:
> What about a 3rd one of these prefixes: "novcs", to teach automake
> about which files belong in VCS or not? i.e. then you might have a
> variable name like:
> dist_novcs_DATA = foo bar baz
> ...which would indicate that foo, bar, and baz are data files that
> ought to be
On Mon, Apr 1, 2024 at 2:26 PM Zack Weinberg wrote:
>
> On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> > "Zack Weinberg" writes:
> >> It might indeed be worth thinking about ways to minimize the
> >> difference between the tarball "make dist" produces and the tarball
> >> "git archive"
On Sun, Mar 31, 2024 at 6:19 PM Peter Johansson wrote:
>
>
> 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
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> "Zack Weinberg" writes:
>> It might indeed be worth thinking about ways to minimize the
>> difference between the tarball "make dist" produces and the tarball
>> "git archive" produces, starting from the same clean git checkout,
>> and also
"Zack Weinberg" writes:
> I have been thinking about this incident and this thread all weekend and
> have seen a lot of people saying things like "this is more proof that
> tarballs are a thing of the past and everyone should just build straight
> from git". There are a bunch of reasons why one
On Sun, Mar 31, 2024, at 3:17 AM, Jacob Bachmeyer wrote:
> 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`
>>
> 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,
>>>
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
On Mar 30, 2024, Eric Gallager wrote:
> automake's `distcheck` target, whose entire purpose is to make it
> easier to verify that a distribution tarball can be rebuilt from
> itself and contains all the things it ought to contain.
> Recommending the `distcheck` target to a wider variety of
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 maintainer, ...
I agree that
Eric Gallager wrote:
> > * In order to detect that a tarball contains too many files, that is,
> > some files that the release manager did not intend to include,
> > the best way is to compare the file list of the current tarball
> > with the previous version:
> > $ diff -r -q
On Sat, Mar 30, 2024 at 5:41 PM Bruno Haible wrote:
>
> Eric Gallager wrote:
> > Recommending the `distcheck` target to a wider variety of users would
> > help more projects catch mismatches between things a distribution
> > tarball is supposed to contain, and things that it isn't.
>
> While
Eric Gallager wrote:
> Recommending the `distcheck` target to a wider variety of users would
> help more projects catch mismatches between things a distribution
> tarball is supposed to contain, and things that it isn't.
While 'make distcheck' detects some of these mismatches, it does not
detect
`distcheck` target's prominence to recommend it in the "Standard
Targets for All Users" section of the GCS?
Replying as an Automake developer, I have nothing against it in
principle, but it's clearly up to the GNU coding standards
maintainers. As far as I know, that's still rms (for
I was recently reading about the backdoor announced in xz-utils the
other day, and one of the things that caught my attention was how
(ab)use of the GNU build system played a role in allowing the backdoor
to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4
Specifically, what
68 matches
Mail list logo
