[bug#42380] [PATCH] gnu: Add torbrowser-unbundle.

[Efraim Flashner]

On Wed, Sep 09, 2020 at 09:20:08AM +0200, Ludovic Courtès wrote:
> Hi André,
> 
> André Batista <nandre@riseup.net> skribis:
> 
> > Just a small token of my appreciation for your years of work on
> > guix. I'm glad to be able to give something back to this community.
> 
> Thank you.
> 
> > I've been using this package for the last month or so and did not
> > hit any bugs so, though I'm not a heavy web user, I think it's fair
> > to say the result is functional.
> >
> > On the down side, the https-everywhere extension is broken as is
> > since it's missing lib-wasm. I've built but did not send here a
> > version which just copies lib-wasm to its proper place before
> > building the extension and this version works without further
> > issues.
> >
> > The reason I did not send it to this list is that lib-wasm source
> > provides a precompiled prepackaged file[1] which is then used on
> > https-everywhere build script and it's source code is not actualy
> > compiled[2]. As I understand it, the Tor Project just relies on
> > this precompiled binary on its build procedure and the same seems
> > to be true for IceCat[3][4].
> 
> Oh, glad that you were able to identify that issue, which presumably had
> been overlooked so far.
> 
> > In order to have everything compiled from source, I've had to
> > define a lot of rust libs which were required for building
> > wasm-pack and then to have a rustc with wasm32-unknown-unknown
> > target enabled and compatible with wasm-pack (apparently newer
> > versions changed compiler strings and wasm-pack errors out when
> > trying to parse). For over two weeks I've been trying without
> > success and always thinking that the next build would succeed.
> >
> > Long story short, maybe there's just one more issue pending when
> > compiling lib-wasm. When wasm-pack is invoked, everything
> > compiles but I'm getting the following error:
> >
> > note: lld: error: 
> > /gnu/store/kwdsf42z7ib6fr5vggqi9nc4jpi1znxy-rust-1.38.0/lib/rustlib/wasm32-unknown-unknown/lib/libstd-373ca16e620a2f9a.rlib:
> >  archive has no index; run ranlib to add one
> >
> > for a few rust libs. Without lld, it complains about a missing
> > rust-lld binary. Also, this appears to be the rust standard
> > nowadays[5].
> 
> Ah.  I’m Cc’ing Efraim, who’s been very much into Rust packaging for
> some time; does that ring a bell, Efraim?
> 

It's not something that I've come across before. My first guess would be
to check the linking flags against the ones icecat/firefox uses and see
if anything changed. Or if it needs a different version of rust.

> > If I'm not terribly wrong, this issue[6] seems to suggest an
> > approach for emscripten which could solve this issue without
> > removing the 'strip' phase which was the work around suggested
> > by some on the same thread.
> >
> > Another issue that is pending is that libwasm depends on rust
> > multi-default-trait-impl crate. This crate defines lgpl2.1+ on
> > its Cargo.toml file, but the sources does not contain neither a
> > copy of the license. So I'm unsure if this is enough to make it
> > free software. So I'm planning on sending some mails to both the
> > maintainer and FSF to see if this needs improvement.
> 
> Great.
> 
> >> For the final submission, we’d need one patch per new package, as is
> >> customary.  That will have the advantage of allowing review to proceed
> >> one bit at a time.  :-)
> >
> > For sure. I'll give it a few more tries and cleanup the mess
> > here before sending this patch series. If I don't succeed, I'm
> > planning on sending it anyway so at least the libs can be
> > added and maybe someone can spot what I'm missing. But maybe
> > it's wise to hold Tor Browser itself since there has been an
> > announcement of some large percentage of exit relays messing
> > with Tor traffic[7].
> 
> I don’t think Guix users will radically increase traffic over Tor, so I
> think we can keep going.  :-)
> 
> >> Regarding Tor Browser itself, can you think of ways to factorize code
> >> with IceCat?
> >
> > Other than sharing the https-everywhere definition, I was
> > thinking maybe we could take a diff of Tor Browser and Firefox
> > and avoid downloading firefox source twice when building both
> > browsers. But I need to take a more careful look. I'll give
> > this question some thought.
> 
> OK.  I was expecting at least things like some of the build phases and
> most/all of the inputs to be the same, but I haven’t checked.
> 
> Thanks again for all the work!
> 
> Ludo’.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature