Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Florian Weimer via Gcc
* 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

Patches submission policy change

2024-04-03 Thread Christophe Lyon via Gcc
Dear release managers and developers, TL;DR: For the sake of improving precommit CI coverage and simplifying workflows, I’d like to request a patch submission policy change, so that we now include regenerated files. This was discussed during the last GNU toolchain office hours meeting [1] (2024-03

Re: Patches submission policy change

2024-04-03 Thread Jan Beulich via Gcc
On 03.04.2024 10:22, Christophe Lyon wrote: > Dear release managers and developers, > > TL;DR: For the sake of improving precommit CI coverage and simplifying > workflows, I’d like to request a patch submission policy change, so > that we now include regenerated files. This was discussed during th

Re: Patches submission policy change

2024-04-03 Thread Jakub Jelinek via Gcc
On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > Any concerns/objections? I'm all for it, in fact I've been sending it like that myself for years even when the policy said not to. In most cases, the diff for the regenerated files is very small and it helps even in patch review t

Re: Patches submission policy change

2024-04-03 Thread Jan Beulich via Gcc
On 03.04.2024 10:45, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: >> Any concerns/objections? > > I'm all for it, in fact I've been sending it like that myself for years > even when the policy said not to. In most cases, the diff for the > regenerated fi

Re: Patches submission policy change

2024-04-03 Thread Richard Biener via Gcc
On Wed, 3 Apr 2024, Jan Beulich wrote: > On 03.04.2024 10:45, Jakub Jelinek wrote: > > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > >> Any concerns/objections? > > > > I'm all for it, in fact I've been sending it like that myself for years > > even when the policy said not t

Re: Patches submission policy change

2024-04-03 Thread Jonathan Wakely via Gcc
On Wed, 3 Apr 2024 at 09:46, Jakub Jelinek via Gcc wrote: > > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > > Any concerns/objections? > > I'm all for it, in fact I've been sending it like that myself for years > even when the policy said not to. In most cases, the diff for t

Re: Patches submission policy change

2024-04-03 Thread Jan Beulich via Gcc
On 03.04.2024 10:57, Richard Biener wrote: > On Wed, 3 Apr 2024, Jan Beulich wrote: >> On 03.04.2024 10:45, Jakub Jelinek wrote: >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: Any concerns/objections? >>> >>> I'm all for it, in fact I've been sending it like that myself f

Re: Patches submission policy change

2024-04-03 Thread Joel Sherrill
Another possible issue which may be better now than in years past is that the versions of autoconf/automake required often had to be installed by hand. I think newlib has gotten better but before the rework on its Makefile/configure, I had a special install of autotools which precisely matched what

Re: Patches submission policy change

2024-04-03 Thread Jason Merrill via Gcc
On Wed, Apr 3, 2024 at 6:23 AM Jan Beulich via Gcc wrote: > On 03.04.2024 10:57, Richard Biener wrote: > > On Wed, 3 Apr 2024, Jan Beulich wrote: > >> On 03.04.2024 10:45, Jakub Jelinek wrote: > >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > Any concerns/objections? >

Re: Patches submission policy change

2024-04-03 Thread Christophe Lyon via Gcc
On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: > > On 03.04.2024 10:22, Christophe Lyon wrote: > > Dear release managers and developers, > > > > TL;DR: For the sake of improving precommit CI coverage and simplifying > > workflows, I’d like to request a patch submission policy change, so > > that

Re: Patches submission policy change

2024-04-03 Thread Christophe Lyon via Gcc
On Wed, 3 Apr 2024 at 12:21, Jan Beulich wrote: > > On 03.04.2024 10:57, Richard Biener wrote: > > On Wed, 3 Apr 2024, Jan Beulich wrote: > >> On 03.04.2024 10:45, Jakub Jelinek wrote: > >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > Any concerns/objections? > >>> > >>

Re: Patches submission policy change

2024-04-03 Thread Christophe Lyon via Gcc
On Wed, 3 Apr 2024 at 14:59, Joel Sherrill wrote: > > Another possible issue which may be better now than in years past > is that the versions of autoconf/automake required often had to be > installed by hand. I think newlib has gotten better but before the > rework on its Makefile/configure, I ha

How to get the default values for parameters?

2024-04-03 Thread Hanke Zhang via Gcc
Hi, I'm trying to get the default values for parameters of some functions in my GIMPLE-PASS. The example code is here: enum { edefault1 = 1, edefault2 = 2, edefault3 = 3 } void func(int p0, int p1 = edefault1, int p2 = edefault2, int p3 = edefault3) { // do other things } I want to get t

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Joel Sherrill
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Michael Matz via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Tom Tromey
> "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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Paul Koning via Gcc
> 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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Martin Uecker via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Jeff Law via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Jeffrey Walton via Gcc
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

Re: Patches submission policy change

2024-04-03 Thread Simon Marchi via Gcc
On 4/3/24 4:22 AM, Christophe Lyon via Gdb wrote: > Dear release managers and developers, > > TL;DR: For the sake of improving precommit CI coverage and simplifying > workflows, I’d like to request a patch submission policy change, so > that we now include regenerated files. This was discussed dur

Re: How to get the default values for parameters?

2024-04-03 Thread Jason Merrill via Gcc
On Wed, Apr 3, 2024 at 9:35 AM Hanke Zhang via Gcc wrote: > > Hi, > I'm trying to get the default values for parameters of some functions > in my GIMPLE-PASS. The example code is here: > > enum { > edefault1 = 1, > edefault2 = 2, > edefault3 = 3 > } > > void func(int p0, int p1 = edefault1,

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Michael Matz via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Joel Sherrill
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Martin Uecker via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Andreas Schwab
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 >

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Jonathan Wakely via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Paul Floyd via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Toon Moene
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Paul Koning via Gcc
> 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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Ian Lance Taylor via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Toon Moene
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread 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? > > (And, FWIW, testing for features isn't "complex". And have you looked at > other build syste

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Andreas Schwab
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Jonathan Wakely via Gcc
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

Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Martin Uecker via Gcc
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? > > > > (

Re: GSoC Timeline Review

2024-04-03 Thread Eric Feng via Gcc
Hi Nada, Apologies for not being able to reply earlier as well. I’m glad to hear you’re interested in continuing this project! There is still a lot of work to be done — my work from last summer is in a very prototype stage. As David mentioned, familiarizing myself with the analyzer took some time,