GNU bug report logs - #67512
[PATCH 0/5] Add LibreWolf

Previous Next

Full log

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

From: Clément Lassieur <clement <at> lassieur.org>
To: Ian Eure <ian <at> retrospec.tv>
Cc: 67512 <at> debbugs.gnu.org, Mark H Weaver <mhw <at> netris.org>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [bug#67512] [PATCH v4 3/4] gnu: Add wasm packages.
Date: Thu, 22 Feb 2024 11:19:03 +0100

On Wed, Feb 21 2024, Ian Eure wrote:

> Clément Lassieur <clement <at> lassieur.org> writes:
>
>> On Wed, Feb 21 2024, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure:
>>>> Clément Lassieur <clement <at> lassieur.org> writes:
>>>>  > > Are you saying you want a process like:
>>>> > >  > > 1a. Get wasm toolchain stuff merged.
>>>> > > 1b. Get Librewolf merged without WASM sandboxing.
>>>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to  > > use  > >
>>>> WASM sandboxing.
>>>> >  > Excatly.  1b can be done after 1a, or before 1a.
>>>> > Is there a technical reason why landing WASM sandboxing support for all
>>>> browsers in the same patch is desirable?  I can intuit none, and as I’m
>>>> disinclined to either roll back portions of my existing patchset, or work
>>>> on other browsers, the proposal is disagreeable.
>>> I think this ordering is w.r.t. *patch sets*, not patches.  I wouldn't
>>> suggest dropping four packages into one patch.
>>
>> Indeed I've never said it should be done in one patch.  I said one-shot
>> as in ‘symmetrical’: the work required to add Wasm to our browsers
>> should be more or less the same for all browsers, and code duplication
>> should be avoided.
>>
>
> Forgive me for my imprecision, and thank you for the
> explanation. Unfortunately, the distinction makes little difference to me, as
> it still would require me to do work I’m unwilling to do.  My unwillingness
> has less to do with the amount of work than its scope: My goal is to get
> LibreWolf into Guix, and I simply have no desire or motivation to work on
> other browsers.

Firefox based browsers are closely related.  Sounds impossible to me to
really do good work on one of them without touching the other ones.

> I think the best course of action is to reduce scope by removing the WASM
> component of this patch series entirely.  I’d send a new patch series without
> the WASM toolchain packages, and with WASM sandboxing disabled in the
> LibreWolf package.  The official LibreWolf binaries don’t appear to have this
> enabled, so no hardening would be sacrified vs. LibreWolf installed any other
> way.  And since I’m not the original author of the WASM packages, and not
> well-positioned to address problems with them, omitting them seems likely to
> circumvent difficulties in the review process and support of those.
>
> What do you think?

Sounds good.  And we can add WASM later.

Previous Next

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