Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.security > #6087

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-19 12:20 +0200
Message-ID <EdT7H-9LhK-3@gated-at.bofh.it> (permalink)
References (5 earlier) <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> <EdDFD-9BGs-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


   Today I have received response on my g++ bug report at gcc.gnu.org. 
Gcc 8.3.0 as used in Debian 10 is no longer supported as the 8 branch 
has a newer version which is gcc 8.5. Why do Debian maintainers not 
update gcc, if there is a known bug that prevents updated sources like 
firefox-esr-91.8.0 from building?

Elmar

On 18.04.22 19:44, Elmar Stellnberger wrote:
>   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 | NextPrevious 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