Re: [SECURITY] [DSA 5113-1] firefox-esr security update

From	Elmar Stellnberger <estellnb@elstel.org>
Newsgroups	linux.debian.security
Subject	Re: [SECURITY] [DSA 5113-1] firefox-esr security update
Date	2022-04-18 19:50 +0200
Message-ID	<EdDFD-9BGs-1@gated-at.bofh.it> (permalink)
References	(4 earlier) <EbRMJ-8xs7-5@gated-at.bofh.it> <Ecx9f-8Wxt-3@gated-at.bofh.it> <EcRhD-98Qm-5@gated-at.bofh.it> <EcSx3-99tF-1@gated-at.bofh.it> <EdfjY-9mR0-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

  The patch from yesterday could be tested by manually shipping the 
executable. Today I have developed another patch (since the first one 
did not resolve it), one that compares against the backtrace with Debian 
11 which is known to have a working gcc. The assumption that the Firefox 
and Qt5/moc bug both have gcc as a cause is likely not valid as Firefox 
stopped with an internal compiler error while moc may produce spurious 
output for some totally different reason.
   You can find the new patch here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

   However this time absolutely no chance to test it by me! Compilation 
did not work though only one line of source had been moved up and even a 
safety copy of the old g++ got deleted at me (and I have not done that).

On 17.04.22 17:46, Elmar Stellnberger wrote:
>    I have now downloaded the source package and examined the backtrace 
> of building Firefox and examined all the differences between gcc 8.3.0-1 
> (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be 
> good for moc/Qt5 from Ubuntu 19.10. There was only one difference I 
> found along the backtrace for gcc and I have documented this in the 
> following gcc/g++ bug report. You can also download the patch from here:
>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
> 
> I have rebuilt with the posted patch and the output has shown me that 
> all package files must have been created successfully:
> 
> Build Dependencies:
> Desired=Unknown/Install/Remove/Purge/Hold
> | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 
> 
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name                      Version                Architecture 
> Description
> +++-=========================-======================-============-=============================================================================== 
> 
> ii  binutils                  2.31.1-16              i386         GNU 
> assembler, linker and binary utilities
> ii  binutils-common:i386      2.31.1-16              i386         Common 
> files for the GNU assembler, linker and binary utilities
> ii  binutils-hppa64-linux-gnu 2.31.1-16              i386         GNU 
> assembler, linker and binary utilities targeted for hppa64-linux
> ii  binutils-i686-linux-gnu   2.31.1-16              i386         GNU 
> binary utilities, for i686-linux-gnu target
> ii  g++-8                     8.3.0-6                i386         GNU 
> C++ compiler
> ii  g++-8-dbgsym              8.3.0-6                i386         debug 
> symbols for g++-8
> ii  g++-8-multilib            8.3.0-6                i386         GNU 
> C++ compiler (multilib support)
> ii  g++-multilib              4:8.3.0-1              i386         GNU 
> C++ compiler (multilib files)
> ii  libc6:i386                2.28-10+deb10u1        i386         GNU C 
> Library: Shared libraries
> ii  libgmp-dev:i386           2:6.1.2+dfsg-4+deb10u1 i386 Multiprecision 
> arithmetic library developers tools
> ii  libisl-dev:i386           0.20-2                 i386 manipulating 
> sets and relations of integer points bounded by linear constraints
> ii  libmpc-dev:i386           1.1.0-1                i386 multiple 
> precision complex floating-point library development package
> ii  libmpfr-dev:i386          4.0.2-1                i386 multiple 
> precision floating-point computation developers tools
> 
> 
> (from gcc-bug:, this is terror by Western secret services, as also 
> referenced by elstel.org/DualSat) "I have looked into the same directory 
> as before but unfortunately I found not a single .deb there and nowhere 
> else under /usr/src. The files can only have been deleted like the ssh 
> user from /etc/passwd at my nslu2 machine. Another time I found out 
> about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my 
> nslu2 via ssh any more. This looks very similar as what I have 
> experienced with arm-linux-gnueabihf-ld when the program did neither 
> produce an error message, an !=0 return value and no output file as 
> given with -o txtfmt."
>    If you know programs like gcc or the linker ld, then you know they 
> will always produce an error message if something fails. Even if there 
> was a bug in ld to display no error it would have returned a non-zero 
> exit status. Anyone who has worked with tools like gcc or ld/collect2 
> knows that. I have really searched for a txtfmt/a.out everywhere possible.
> 
>    I am quite sure that the posted patch would resolve the issue. I 
> would appreciate it very much if someone was ready to compile that with 
> a Debian10/i386 chroot:
> 
> as root:
>   > debootstrap --arch i386 buster /dst/dbuster-i386
>   > xchroot /dst/dbuster-i386
>   > ... install build-essential apt-src locales-all etc.
>   > cd /usr/src
>   > apt-src update
>   > apt-src install gcc-8
> 
> Compiling may need more than a day; however you may hibernate in 
> between. Make sure you have copied the patch into 
> gcc-8-8.3.0/debian/patches/ and check that file has been patched some 
> good minutes after compilation has started:
> 
> grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c || echo ok
> 
> before it should not echo ok but the line with chkp_reset_rtl_bounds
> 
> invoke the build inside the gcc-8-8.3.0 directory:
>    dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
> // -b ... build binary
> // -uc -us ... do not sign (I use -kestellnb@elstel.org, see gpg 
> --list-keys)
> 
>    You can stop as soon as it has created the .deb packages. Grep for a 
> line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out. Do 
> not forget to shield the + characters of g++ i.e. grep 
> "g[+][+]-8-multilib "
> 
>    It will be of great help if anyone decides to do so!
> Remember it should resolve several dependent bugs in Buster/i586 and 
> also distributions of similar time.
> 
> Regards,
> Elmar
> 
> 
> 
> 
> On 16.04.22 17:20, Odo Poppinger wrote:
>> Why not?
>>
>> On 16.04.22 16:05, Elmar Stellnberger wrote:
>>  >    Given that this should not be possible for some reason, please
>>  > share your knowledge about these bugs, so that people like me
>>  > can try to find a fix.
>>  >
>>  > Elmar
>>
>>
>> On 11.04.22 23:57, Moritz Muehlenhoff wrote:
>>> It is possible; if someone tracks down the respective GCC change and 
>>> backports
>>> it to GCC 8 in Buster or alternatively lands a patch in the ESR91 branch
>>> which changes the code to no longer trigger the ICE, that would fix it.
>>>
>>> But realistically the number of people who actively care about i386 
>>> support is
>>> really, really small so I wouldn't count on it...
>>>
>>> Cheers,
>>>          Moritz
>>

Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: [SECURITY] [DSA 5113-1] firefox-esr security update Friedhelm Waitzmann <fach220408.fwnsp@xoxy.net> - 2022-04-08 14:20 +0200
  Re: [SECURITY] [DSA 5113-1] firefox-esr security update Moritz Mühlenhoff <jmm@inutil.org> - 2022-04-09 23:40 +0200
    Re: [SECURITY] [DSA 5113-1] firefox-esr security update Odo Poppinger <odopopp@gmail.com> - 2022-04-11 13:50 +0200
      Re: [SECURITY] [DSA 5113-1] firefox-esr security update Moritz Muehlenhoff <jmm@inutil.org> - 2022-04-12 00:10 +0200
    amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) Friedhelm Waitzmann <fach220408.fwnsp@xoxy.net> - 2022-04-12 06:20 +0200
      Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) piorunz <piorunz@gmx.com> - 2022-04-13 16:50 +0200
        Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY]  [DSA 5113-1] firefox-esr security update) Michael Stone <mstone@debian.org> - 2022-04-13 17:10 +0200
          Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) piorunz <piorunz@gmx.com> - 2022-04-13 17:20 +0200
            Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) Odo Poppinger <odopopp@gmail.com> - 2022-04-13 17:40 +0200
              Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY]  [DSA 5113-1] firefox-esr security update) Michael Stone <mstone@debian.org> - 2022-04-13 18:00 +0200
      Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) Elmar Stellnberger <estellnb@elstel.org> - 2022-04-14 10:50 +0200
      Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) Levis Yarema <levisyarema91@gmail.com> - 2022-04-14 15:50 +0200
        Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA  5113-1] firefox-esr security update) Elmar Stellnberger <estellnb@elstel.org> - 2022-04-15 09:10 +0200
    Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-13 22:10 +0200
      Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-13 22:30 +0200
        Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-15 18:40 +0200
          Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-16 16:10 +0200
            Re: [SECURITY] [DSA 5113-1] firefox-esr security update Odo Poppinger <odopopp@gmail.com> - 2022-04-16 17:30 +0200
              Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-17 17:50 +0200
                Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-17 18:10 +0200
                Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-17 18:20 +0200
                Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-18 19:50 +0200
                Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-19 12:20 +0200
                Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-05-07 15:50 +0200
    Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-14 15:00 +0200
      Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-14 19:00 +0200
        Re: [SECURITY] [DSA 5113-1] firefox-esr security update Friedhelm Waitzmann <fach220408.fwnsp@xoxy.net> - 2022-04-15 05:10 +0200
    Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@elstel.org> - 2022-04-14 15:00 +0200
    Re: [SECURITY] [DSA 5113-1] firefox-esr security update Elmar Stellnberger <estellnb@gmail.com> - 2022-11-18 16:50 +0100

csiph-web