Re: Switching GNU IceCat to follow upstream candidates (Amin Bandali)

[Amin Bandali]

Hi Adam, (Mark, all,)

Mark H Weaver writes:

> Hi Adam,
>
> Adam Faiz <adam.faiz@disroot.org> writes:
>> Would other big changes to IceCat be accepted? I sent my ideas for the
>> roadmap about 2 years ago but I got no feedback:
>> https://lists.gnu.org/archive/html/gnuzilla-dev/2022-12/msg00000.html
>
> The only specific suggestion I see there is to add support for
> unbundling many of the libraries that are currently bundled by upstream
> Firefox.  In the past, I made some efforts along these lines in the Guix
> packaging for IceCat, and some vestigial remnants of those efforts still
> remain in the Guix repository, although they are long unused.
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/icecat-use-system-graphite2+harfbuzz.patch?id=5e66832ad47a2f4222ccf681c39266cfc9fc1f15
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/icecat-use-system-media-libs.patch?id=5e66832ad47a2f4222ccf681c39266cfc9fc1f15
>    
>
> With the update to IceCat 102, I found that these patches no longer
> applied, and since then, I've not found the time/energy/interest to
> maintain them.
>
> Moreover, even if volunteers showed up to keep patches like these
> "working", by which I mean "not obviously broken", there's another
> question worth asking: would we be unintentionally introducing security
> vulnerabilities by unbundling these libraries?  It's not a trivial
> question to answer.  At minimum, I would want us to keep a close eye on
> any security fixes applied to the bundled libraries, and implement
> checks to make sure that the system libraries used by IceCat also
> included those fixes.  This job is made more difficult by the fact that
> not all fixes to bundled libraries that have security implications will
> be explicitly identified as security fixes, because in general it is
> nontrivial to find out whether any given bug can be exploited.
>
> In my opinion, the IceCat project does not, at this time, have enough
> developer energy to take on the job of maintaining patches such as
> these.  I welcome other opinions.
>
>       Regards,
>         Mark
>

Thank you for the contribution and feedback, Adam, and sorry that you
didn't get a response about this earlier.  I tend to agree with Mark,
in that I like the idea of unbundling dependencies where possible, but
especially in the case of a web browser, there are potential pitfalls
to be mindful of when it comes to security, and also the sheer scope
of the work involved.

As far as I can tell, neither Debian/Ubuntu and their derivatives like
Trisquel nor other free distros like Parabola that I know of unbundle
their Firefox deps, so we'd pretty much be on our own, at least when
initially starting out.  And like Mark, I'm not sure I'd have the
needed energy/bandwidth to take on doing so myself, but maybe that
could be a good reason for cross-distro collaboration, if there's time
and shared interest for it.

Would you be interested and able to take initiative working on this?
If so, I'd suggest one of your actions be reaching out to maintainers
of Firefox(-derived) packages in distros like Parabola and Trisquel
and see if they may be interested in helping out.  Also, Mike Hommey,
the maintainer of Firefox in Debian, works at Mozilla and it might be
good to also try asking him (and other Mozilla folks) about this and
see if they may have any specific thoughts/suggestions.

One potential complication that just now occurred to me for unbundling
e.g. the hundreds of the Rust dependencies is for distros like Debian
and Trisquel with a stable release model, where at least one major
Firefox ESR version bump would fall in the duration of their current
stable release.  Considering upstream's fairly aggressive stance on
bumping the minimum required version of their dependencies, those
distros could be looking at a nightmare scenario of having to update
tens if not hundreds of packages in the middle of their release cycle,
which would either be very challenging or outright not work, due to
flying in the face of their stable release model.  So, I think
realistically, doing something like this would only work for rolling
distros like Guix and Parabola, and maybe those with much shorter
stable release cycles than e.g. Debian.

As for GNU IceCat bugs in general, please do report them to
bug-gnuzilla@gnu.org and we'll try to address them as best as we can.

Best,
-a