[bug#71782] [PATCH v5 3/4] gnu: torbrowser: Update to 13.5.3 [security fixes].

[Ian Eure <ian@retrospec.tv>]

Hi André,

André Batista <nandre@riseup.net> writes:

> Hi Ian,
>
> sex 06 set 2024 às 08:05:28 (1725620728), ian@retrospec.tv 
> enviou:
>> 
>> This all looks good to me.  I built and ran both browsers and 
>> they seem to
>> be working how I’d expect.
>
> Great, thanks!
>
>> My only question is around the locale handling -- (gnu packages 
>> gnuzilla)
>> has a setup for these which I was able to reuse for LibreWolf. 
>> Is that
>> possible for mullvad and torbrowser?  It would be nice to have 
>> a unified way
>> of handling this, instead of each browser implementing its own 
>> strategy.
>> 
>
> I'm not sure I understand why you think this to be desirable, 
> could you
> elaborate?
>

There’s a lot of duplication between the Firefox-derived browsers 
in Guix, and I think it would be good to reduce it where it makes 
sense.  Because the locales are a separate package used as an 
input, this seems like a part of them which could be handled in a 
uniform way, to the benefit of all (assuming they use the same 
locale data).


> I'm also not sure if this is possible (without incuring in 
> glitches) and
> in my opinion this is not desirable for both torbrowser and 
> mullvad
> because:
>
> I. Both these browsers have modified pristine firefox in a 
> number of
> non-trivial ways. Eg.: if you go to about:preferences you will 
> see that
> there are various user settings which are specific to this 
> browsers or
> even when you first launch torbrowser the connection settings 
> page is
> unknown to firefox. I believe that's the reason why these 
> browsers do
> not support 'all-mozilla-locales', but just a subset which has 
> been
> worked upon by the torproject.
>

I see, now that I read the patch more closely, it looks like the 
upstream locale data wasn’t being used, despite reusing the 
`mozilla-locale' code from Gnuzilla.

> II. In order to avoid guix users having a different fingerprint, 
> we try
> to be as close as possible to what upstream does. I'm not sure 
> if locale
> version could be somehow infered from the network, but I guess 
> using the
> same version is the safest bet;
>
> III. Currently on guix master, these browsers are using code 
> copied from
> gnuzilla.scm, but with a subset of locales and different 
> changesets
> that are based on torproject settings. However, torproject has 
> moved
> from mercurial to the unified github firefox locales[1] which 
> has
> immensily simplified the work required to update the changesets 
> (now
> actually commits) and all locales supported on those browsers 
> now have
> only one commit, instead of various changesets on single locale 
> repos;
>

This makes sense to me with the additonal context.


> IV. Moreover, I believe mozilla itself is on the way of 
> deprecating
> mercurial l10n-central in favor of firefox-locales git repo, 
> since
> this is where all work has been happening[2], while l10n-central 
> has
> stopped at 2024-07-10[2]. So probably in a not so distant future
> gnuzilla will have to move on to that as well.
>

I wasn’t aware of this, but that’s great news, as it’ll make 
reproducible builds much easier.  Thank you for letting me know.


> So I stand by the changes proposed on this patch series, at 
> least as
> things stand.
>

Makes sense.  I’m still in favor of merging them.  Thank you for 
taking the time to explain.

Thanks,

  — Ian