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

   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 [email protected], 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
>