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

Previous Next

Full log

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

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

Hi Ian,

Ian Eure <ian <at> retrospec.tv> writes:

> 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.

Perhaps the modifications to make it reproducible could be shared to
upstream?  We'd benefit all thee users of librewolf this way, not only
Guix ones.

> 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.

The "dissatisfaction", if we can call it that, was about Linux-libre,
and voiced by some a few years ago, including the project maintainers,
if I recall correctly.  The idea of linux-libre is to shield users from
blobs.  In this sense it is valuable that they don't even have to touch
the pristine blobbed (there are a few array-defined firmwares in the
tree still, at least one old Apple one IIRC) Linux source, which is
considered problematic for some from a GNU FSDG perspective.

>> 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.

Right.

> 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.

OK, this flexibility seems indeed useful here.

> 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.

Yes, you are the one doing it (thank you!) until you won't :-)
(life...).  Then someone else would have to pick it up and understand
it.  The simpler the better.

> 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.

The 22kloc patch doesn't sound too good... I guess we can stick with the
self-made tarball for now.

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

Sorry for the delay handling this security-sensitive issue (still better
than our ungoogled-chromium package which appears untouched for a full
year, though!  We should probably open a security issue about that).

If you could send v2 with the build id thing, I'll try to apply it
quickly.

-- 
Thanks,
Maxim

Previous Next

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