On 15/10/2022 08:27, Adrian Bunk wrote:
Package: firefox-esr
Version: 102.3.0esr-1
Severity: serious
Tags: bookworm sid
X-Debbugs-Cc: Carsten Schoenert <c.schoen...@t-online.de>,
debian-rele...@lists.debian.org, t...@security.debian.org, debian-...@lists.debian.org
[ various potentially interested parties are Cc'ed ]
4 GB address space for one process is an absolute limit on 32bit
architectures, including for native building as is done in Debian.[1]
mipsel has 2 GB address space (all Debian buildds have 64bit kernels),
the 2020 Firefox ESR (78) was the last Firefox ESR to build there.
On i386 and 32bit arm:
4 GB address space are available with a 64bit kernel.
3 GB address space are typically available with a 32bit kernel.
All i386 buildds are using a 64bit kernel,
but armhf buildds are currently mixed.
That is about to change (once linux-signed hits bullseye-backports). All armhf
builds will be running on arm64 buildds.
This uncovered that the 2022 ESR of Firefox (102) already needs
more than 3 GB address space on armhf.[2]
There is a new ESR major release of Firefox every summer,
which is being used also in *stable releases of Debian since the
previous ESR branch loses upstream security support soon afterwards.
It is possible to confine building firefox{,-esr} to only the 64bit
buildds on the buildd side to address the current issue,[3] but during
the non-LTS lifetime of bookworm firefox-esr will be upgraded three
times to newer ESR major releses.
One can hope the 2023 ESR might still be buildable with 4 GB address space,
which would cover the non-LTS support time of bullseye.
I would be less optimistic that the 2025 ESR will still be buildable
with 4 GB address space, which implies that it might not be possbile
to provide security support for firefox-esr on i386 and 32bit arm
during the whole non-LTS support time of bookworm.
The above considerations might also apply to whether or not
thunderbird/i386 should be provided in bookworm.
I don't see why we should preemptively remove firefox from architectures for a
build issue that may or may not happen 3 years from now. If it happens and we
can't fix/workaround it, then we can discontinue FF security updates there. But
until then, I think providing FF is better than not providing it.
Cheers,
Emilio
