GNU bug report logs - #71121
[PATCH 0/3] Update LibreWolf to 126.0-1 [security fixes]

Previous Next

Full log

Message #20 received at 71121 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 71121 <at> debbugs.gnu.org
Subject: Re: [bug#71121] [PATCH 2/3] gnu: librewolf: Rebuild source tarball
Date: Wed, 29 May 2024 18:48:11 -0700

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi Ian,
>
> Ian Eure <ian <at> retrospec.tv> writes:
>
>> * gnu/packages/librewolf.scm (librewolf): This patch removes an 
>> intermediate
>> step in the build chain.  The upstream source tarball is 
>> created with an
>> automated build process, where Firefox sources are fetched, 
>> patched, and
>> repacked.  Rather than download the output of that process, as 
>> the package has
>> been, it’s now replicated within the build process, similar to 
>> how IceCat
>> works.
>
> I think I'd rather keep using a human-prepared and vetted 
> tarball, to
> avoid anything going stale in our local recipe of how it's meant 
> to be
> prepared.
>

The upstream tarball is built by scripts run under a CI system 
which triggers when changes are pushed[1], and aren’t 
human-prepared or vetted in the same way that many release 
tarballs have tradionally been.  This patchset uses the same 
script as upstream, with modifications to make it reproduceable, 
as the upstream process isn’t.

As noted in the commit messages, IceCat also builds this way[2], 
including patching the upstream build script[3][4], so this seems 
like a reasonable & accepted way to build.  Though perhaps there’s 
dissatisfaction with the IceCat build which I wasn’t aware of, 
being a fairly new contributor.


> It's also simpler and less maintenance, and arguably shields
> the users better against non-free source code (although I don't 
> think
> there's anything non-free in the Firefox tree, so that point is 
> more
> moot than say, for linux) to use a tarball.
>
> What do you or others think?
>

It’s definitely simpler to use the upstream tarball in most cases, 
which is why I went that direction when I initially packaged 
LibreWolf.  But, since IceCat builds this way, and the xz backdoor 
was discovered hiding in the non-reproduceable build process, I’ve 
been intending to update the package to control the full build, 
rather than trusting an unreproducable external process.  I 
understand that if the build scripts are backdoored, it doesn’t 
matter whether upstream runs them or Guix does, but I believe that 
aligning with IceCat and having a reproduceable build directly 
from the upstream source repo are worthwhile.

In the specific case of the 126.0-1 release, owning the whole 
build process made things easier.  Upstream backported a very 
large Firefox change[5] which updates a bundled dependency to a 
new version; that dependency doesn’t work with Rust 1.75, which is 
what’s in Guix.  With the Guix build process controlling what 
patches get applied, I was able to solve the problem by removing 
one line from the manifest of patches to apply to the Firefox 
source.  If the package builds from the 126.0-1 tarball, it’ll 
need to ship a 22,000-line patch(!) to back out that change.  That 
may still be necessary, depending on the timing of the rust-team 
branch merging and the next Firefox release, but at least for now, 
things are simpler.  Ideally, this wolud be solved by unbundling 
that (and the other) vendored Rust libraries (and that’s something 
I intend to look into), but I didn’t want to block security fixes 
on work with unknown-but-probably-large scope -- there will almost 
definitely be Rust libraries currently not packaged in Guix which 
need to be addressed.

As far as maintenance burden or things getting stale, the risk is 
that upstream alters their scripts, which requires updates to the 
Guix patches for them.  This doesn’t seem like a major drawback to 
me, and I’m the one doing the maintenance. :)   Overall, I think 
it’s a reasonable tradeoff for the reproducability we gain.  If 
this approach to building LibreWolf in this patchset is acepted, 
I’d like to work with upstream to make their build process more 
flexible, ideally running it unmodified in the Guix build, which 
would eliminate the risk.

Lastly: I noticed that I neglected to update %librewolf-build-id 
when I sent this patchset in.  If my arguments are compelling 
enough for you, I think it’d make sense to update that when the 
changes are pushed (it’s a one-line change & the command to print 
an ID are in the comment above the variable).  But, if you’d like 
a v2 patchset, either just to update that, or to back out the 
build process change and replace it with a 22kloc patch, I’d be 
happy to handle it instead.

Thank you very much for your thoughts and the time you took to 
respond.

 — Ian


[1]: https://codeberg.org/librewolf/source/actions/runs/168/jobs/0
[2]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?id=898b5f30f3d485d48275c920da172863da9524c6#n530
[3]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?id=898b5f30f3d485d48275c920da172863da9524c6#n571
[4]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/icecat-makeicecat.patch
[5]: 
https://codeberg.org/librewolf/source/commit/d292bdd2213a22e5b364339dfee68a27670f1b72

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.