Hi Mark,
On Sun, Apr 21, 2024 at 10:40:14PM +0200, Alejandro Colomar wrote:
[...]
> Let's generate a v2 patch set, showing the range-diff against v1. We
> need to check the commit IDs of the first set, which can be found in the
> mailing list archives, thanks to the trick we used. The v1 range
On Apr 24 2024, Boris Kolpackov wrote:
> https://github.com/build2/libbuild2-autoconf
Welcaome back, imake.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Martin Uecker writes:
> Do we really still need complex build systems such as autoconf? Are
> there still so many different configurations with subtle differences
> that every single feature needs to be tested individually by running
> code at build time?
We have taken the alternative approach i
On Sun, Apr 21, 2024 at 10:40:14PM +0200, Alejandro Colomar wrote:
> On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote:
> > Hi Alejandro,
>
> Hi Mark,
>
> I've reordered your message, to organize my response.
>
> > On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote:
>
On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote:
> Hi Alejandro,
Hi Mark,
I've reordered your message, to organize my response.
> On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote:
> > It would also be interesting to require showing range-diffs between
> > patch rev
Hi Alejandro,
On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote:
> It would also be interesting to require showing range-diffs between
> patch revisions. They make it much more difficult to introduce a
> vulnerability after a reviewer has turned its mins into approving the
> patch
On Mon, 1 Apr 2024 17:06:17 +0200
Mark Wielaard wrote:
> We should discuss what we have been doing and should do more to
> mitigate and prevent the next xz-backdoor.
Since we're working on a compiler, "On Trusting Trust" comes to mind.
Russ Cox posted some thoughts last year that might be appli
Hi -
>This is very true, however a few words of caution: IME this is a
>maintainability nightmare. Fixing patches that forgot to regenerate,
>regenerating on rebase, confirming everything is up-to-date before
>merge, etc etc. It can be handled, I have, but it was painful and
>t
Hi Joel,
On Wed, Apr 03, 2024 at 08:53:21AM -0500, Joel Sherrill wrote:
> On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb
> wrote:
>
> > * Guinevere Larsen via Overseers:
> >
> > > Beyond that, we (GDB) are already experimenting with approved-by, and
> > > I think glibc was doing the same.
>
Hi -
> In Autotools, `make dist` produces a tarball that contains many
> files not present in the source respoitory, it includes build system
> core files and this fact was used for the xz attack. In contrast,
> for newer build systems the "release tarball" is purely a snapshot
> of the source rep
On 09/04/2024 18:57, Andreas Schwab wrote:
> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
>
>> - This xz backdoor injection unpacked attacker-controlled files and ran them
>> during `configure`. Newer build systems implement a build abstraction (aka
>> DSL) that acts similar to a sandbo
On 4/9/24 15:22, Sam James wrote:
Paul Eggert writes:
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
To be clear - not saying it's immune.
Sure, but someone who
Paul Eggert writes:
> On 4/9/24 14:58, Sam James wrote:
>> Meson doesn't allow user-defined functions
>
> Meson has ways to execute arbitrary user-defined code, so it's not
> immune to this sort of exploit.
To be clear - not saying it's immune. Just that it scopes the
user-defined code part to c
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
It's of course better (all other things being equal) to use a build
system with a smaller attack surface. However,
Jonathon Anderson writes:
> On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
>
> On 4/9/24 14:40, Jeffrey Walton wrote:
>
> Code provenance and code integrity was not enforced. Part of the problem is
> the Autotools design. It is from a
> bygone era.
>
> No, Andreas is right. This isn't
On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
> On 4/9/24 14:40, Jeffrey Walton wrote:
>
> > Code provenance and code integrity was not enforced. Part of the
> > problem is the Autotools design. It is from a bygone era.
>
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
Jonathon Anderson via Gdb writes:
> On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote:
>>
>> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
>> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote:
>>
>> > CMake has its own sandbox and rules and escapes (granted, much more of
>> > them). B
Paul Eggert writes:
> On 4/9/24 14:40, Jeffrey Walton wrote:
>> Code provenance and code integrity was not enforced. Part of the
>> problem is the Autotools design. It is from a bygone era.
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
> Most of the Autotools-based projects
On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote:
>
> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote:
>
> > CMake has its own sandbox and rules and escapes (granted, much more of
> > them). But regardless, the injection code would be c
On 4/9/24 14:40, Jeffrey Walton wrote:
Code provenance and code integrity was not enforced. Part of the
problem is the Autotools design. It is from a bygone era.
No, Andreas is right. This isn't an Autotools-vs-Meson thing.
Most of the Autotools-based projects I help maintain would have been
On Tue, Apr 9, 2024 at 4:11 PM Paul Koning via Gdb wrote:
>
> > On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
> > wrote:
> >
> > On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
> >
> >> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
> >>
> >>> - This xz backdoor injection unpacked
> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc wrote:
>
> On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
>
>> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
>>
>>> - This xz backdoor injection unpacked attacker-controlled files and ran
>> them during `configure`. Newer build
On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
>
> > - This xz backdoor injection unpacked attacker-controlled files and ran
> them during `configure`. Newer build systems implement a build abstraction
> (aka DSL) that acts similar to a sand
On Apr 09 2024, anderson.jonath...@gmail.com wrote:
> - This xz backdoor injection unpacked attacker-controlled files and ran them
> during `configure`. Newer build systems implement a build abstraction (aka
> DSL) that acts similar to a sandbox and enforces rules (e.g. the only code
> run duri
Hello,
On Thu, Apr 4, 2024, 09:00 Michael Matz wrote:
> Hello,
>
> On Wed, 3 Apr 2024, Jonathon Anderson wrote:
>
> > Of course, this doesn't make the build system any less complex, but
> > projects using newer build systems seem easier to secure and audit than
> > those using overly flexible
Am Samstag, dem 06.04.2024 um 15:00 +0200 schrieb Richard Biener:
> On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote:
> >
> > >
> > >
> > >
> > > > I think the key difference here is that Autotools allows arbitrarily
> > > generated code to be executed at any time. More modern build
On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote:
>
> >
> >
> >
> > > I think the key difference here is that Autotools allows arbitrarily
> > generated code to be executed at any time. More modern build systems
> > require the use of specific commands/files to run arbitrary code, e.g.
>
>
>
> > I think the key difference here is that Autotools allows arbitrarily
> generated code to be executed at any time. More modern build systems
> require the use of specific commands/files to run arbitrary code, e.g.
> CMake (IIRC [`execute_process()`][2] and [`ExternalProject`][3]), Meson
>
Hello,
On Wed, 3 Apr 2024, Jonathon Anderson wrote:
> Of course, this doesn't make the build system any less complex, but
> projects using newer build systems seem easier to secure and audit than
> those using overly flexible build systems like Autotools and maybe even
> CMake. IMHO using a la
Hi,
On Wed, 2024-04-03 at 08:42 -0600, Jeff Law wrote:
> On 4/3/24 8:04 AM, Tom Tromey wrote:
> > > > > > > "Florian" == Florian Weimer writes:
> >
> > Florian> Everyone still pushes their own patches, and there are no
> > Florian> technical countermeasures in place to ensure that the pushed
>
Hi,
On Wed, 2024-04-03 at 08:53 -0500, Joel Sherrill wrote:
> On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb
> wrote:
> > * Guinevere Larsen via Overseers:
> >
> > > Beyond that, we (GDB) are already experimenting with approved-by, and
> > > I think glibc was doing the same.
> >
> > The g
Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gcc:
> Hello all,
>
> On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote:
> > > My take a way is that software needs to become less complex. Do
> > > we really still need complex build systems such as autoconf?
> >
> > (
On Wed, 3 Apr 2024 at 19:36, Toon Moene wrote:
>
> On 4/3/24 20:25, Ian Lance Taylor wrote:
>
> > Note that the attack really didn't have anything to do with
> > compressing data. The library used an IFUNC to change the PLT of a
> > different function, so it effectively took control of the code t
On Apr 03 2024, Paul Floyd via Gcc wrote:
> On 03-04-24 14:32, Martin Uecker via Gcc wrote:
>
>> The backdoor was hidden in a complicated autoconf script...
>
> How many uncomplicated autoconf scripts exist in the real world?
Probably the same amount as in any other build system. Building
(porta
Hello all,
On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote:
> > My take a way is that software needs to become less complex. Do
> > we really still need complex build systems such as autoconf?
>
> (And, FWIW, testing for features isn't "complex". And have you looked at
> other build syste
On 4/3/24 20:25, Ian Lance Taylor wrote:
Note that the attack really didn't have anything to do with
compressing data. The library used an IFUNC to change the PLT of a
different function, so it effectively took control of the code that
verified the cryptographic key. The only part of the attac
On Wed, Apr 3, 2024 at 11:05 AM Toon Moene wrote:
>
> Two questions arise (as far as I am concerned):
>
> 1. Do daemons like sshd *have* to be linked with shared libraries ?
> Or could it be left to the security minded of the downstream
> (binary) distributions to link it statically with k
> On Apr 3, 2024, at 2:04 PM, Toon Moene wrote:
>
> On 4/1/24 17:06, Mark Wielaard wrote:
>
>> A big thanks to everybody working this long Easter weekend who helped
>> analyze the xz-backdoor and making sure the impact on Sourceware and
>> the hosted projects was minimal.
>
> Thanks for thos
On 4/1/24 17:06, Mark Wielaard wrote:
A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.
Thanks for those efforts !
Now, I have seen two more days of thinking about this vu
On 03-04-24 14:32, Martin Uecker via Gcc wrote:
The backdoor was hidden in a complicated autoconf script...
How many uncomplicated autoconf scripts exist in the real world?
A+
Paul
On Wed, 3 Apr 2024 at 15:34, Martin Uecker via Gcc wrote:
> I ask a very specific question: To what extend is testing
> for features instead of semantic versions and/or supported
> standards still necessary? This seems like a problematic approach
> that may have been necessary decades ago, but i
On Apr 03 2024, Martin Uecker wrote:
> I ask a very specific question: To what extend is testing
> for features instead of semantic versions and/or supported
> standards still necessary? This seems like a problematic approach
> that may have been necessary decades ago, but it seems it may be
>
Am Mittwoch, dem 03.04.2024 um 18:02 +0200 schrieb Michael Matz:
> Hello,
>
> On Wed, 3 Apr 2024, Martin Uecker wrote:
>
> > The backdoor was hidden in a complicated autoconf script...
>
> Which itself had multiple layers and could just as well have been a
> complicated cmake function.
Don't m
On Wed, Apr 3, 2024 at 11:03 AM Michael Matz via Gdb
wrote:
> Hello,
>
> On Wed, 3 Apr 2024, Martin Uecker wrote:
>
> > The backdoor was hidden in a complicated autoconf script...
>
> Which itself had multiple layers and could just as well have been a
> complicated cmake function.
>
> > > (And, F
Hello,
On Wed, 3 Apr 2024, Martin Uecker wrote:
> The backdoor was hidden in a complicated autoconf script...
Which itself had multiple layers and could just as well have been a
complicated cmake function.
> > (And, FWIW, testing for features isn't "complex". And have you looked at
> > other
On Wed, Apr 3, 2024 at 10:33 AM Martin Uecker via Gdb
wrote:
>
> Am Mittwoch, dem 03.04.2024 um 16:00 +0200 schrieb Michael Matz:
> > [...]
> > (And, FWIW, testing for features isn't "complex". And have you looked at
> > other build systems? I have, and none of them are less complex, just
> > op
On 4/3/24 8:04 AM, Tom Tromey wrote:
"Florian" == Florian Weimer writes:
Florian> Everyone still pushes their own patches, and there are no
Florian> technical countermeasures in place to ensure that the pushed version is
Florian> the reviewed version.
This is a problem for gdb as well.
Pr
Am Mittwoch, dem 03.04.2024 um 16:00 +0200 schrieb Michael Matz:
> Hello,
>
> On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote:
>
> > > > Seems reasonable, but note that it wouldn't make any difference to
> > > > this attack. The liblzma library was modified to corrupt the sshd
> > > > binary, wh
> On Apr 3, 2024, at 10:00 AM, Michael Matz wrote:
>
> Hello,
>
> On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote:
>
Seems reasonable, but note that it wouldn't make any difference to
this attack. The liblzma library was modified to corrupt the sshd
binary, when sshd was link
> "Florian" == Florian Weimer writes:
Florian> Everyone still pushes their own patches, and there are no
Florian> technical countermeasures in place to ensure that the pushed version is
Florian> the reviewed version.
This is a problem for gdb as well.
Probably we should switch to some kind
Hello,
On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote:
> > > Seems reasonable, but note that it wouldn't make any difference to
> > > this attack. The liblzma library was modified to corrupt the sshd
> > > binary, when sshd was linked against liblzma. The actual attack
> > > occurred via a con
On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb
wrote:
> * Guinevere Larsen via Overseers:
>
> > Beyond that, we (GDB) are already experimenting with approved-by, and
> > I think glibc was doing the same.
>
> The glibc project uses Reviewed-by:, but it's completely unrelated to
> this. Every
* Guinevere Larsen via Overseers:
> Beyond that, we (GDB) are already experimenting with approved-by, and
> I think glibc was doing the same.
The glibc project uses Reviewed-by:, but it's completely unrelated to
this. Everyone still pushes their own patches, and there are no
technical countermea
Am Dienstag, dem 02.04.2024 um 13:28 -0700 schrieb Ian Lance Taylor via Gcc:
> > On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc wrote:
> > > >
> > > > Would it help to require (rather than just recommend) "don't use root
> > > > except for the actual 'install' step" ?
> >
> > Seems reasonab
On Tue, Apr 2, 2024 at 7:35 PM Paul Koning via Gdb wrote:
> [...]
>
> I agree that GDB, and for that matter other projects with significant numbers
> of contributors, are not nearly as likely to be vulnerable to this sort of
> attack. But I worry that xz may not be the only project that's small
> On Apr 2, 2024, at 6:08 PM, Guinevere Larsen wrote:
>
> On 4/2/24 16:54, Sandra Loosemore wrote:
>> On 4/1/24 09:06, Mark Wielaard wrote:
>>> A big thanks to everybody working this long Easter weekend who helped
>>> analyze the xz-backdoor and making sure the impact on Sourceware and
>>> the
On Tue, Apr 2, 2024 at 6:09 PM Guinevere Larsen via Gdb
wrote:
> [...]
> What likely happened for the maintainer who acted in bad faith was that
> they entered the project with bad faith intent from the start - seeing
> as they were only involved with the project for 2 years, and there was
> much
On 4/2/24 16:54, Sandra Loosemore wrote:
On 4/1/24 09:06, Mark Wielaard wrote:
A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.
This email isn't about the xz-backdoor itsel
On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc wrote:
>
> Would it help to require (rather than just recommend) "don't use root except
> for the actual 'install' step" ?
Seems reasonable, but note that it wouldn't make any difference to
this attack. The liblzma library was modified to corru
> On Apr 2, 2024, at 4:03 PM, Paul Eggert wrote:
>
> On 4/2/24 12:54, Sandra Loosemore wrote:
>> Do we to harden our process, too, to require all patches to be signed off by
>> someone else before committing?
>
> It's easy for an attacker to arrange to have "someone else" in cahoots.
>
> Al
On 4/2/24 12:54, Sandra Loosemore wrote:
Do we to harden our process, too, to require all patches to be signed
off by someone else before committing?
It's easy for an attacker to arrange to have "someone else" in cahoots.
Although signoffs can indeed help catch inadvertent mistakes, they're
r
On 4/1/24 09:06, Mark Wielaard wrote:
A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.
This email isn't about the xz-backdoor itself. Do see Sam James FAQ
https://gist.githu
A big thanks to everybody working this long Easter weekend who helped
analyze the xz-backdoor and making sure the impact on Sourceware and
the hosted projects was minimal.
This email isn't about the xz-backdoor itself. Do see Sam James FAQ
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee7
64 matches
Mail list logo
