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

[André Batista]

Hello,

seg 07 set 2020 às 16:13:17 (1599505997), ludo@gnu.org enviou:
> Hello,
> 
> Woow, thanks for working on this!  The end result is functional, right?
> Any important missing items?

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.

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

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

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.

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

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

Cheers,

1. 
https://docs.rs/crate/https-everywhere-lib-wasm/0.1.2/source/pkg/https_everywhere_lib_wasm_bg.wasm
2. https://github.com/EFForg/https-everywhere/blob/master/make.sh#L113
3. https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat?h=68#n565
4. 
https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/extensions/https-everywhere@eff.org/wasm/https_everywhere_lib_wasm_bg.wasm?h=68
5. https://github.com/rust-lang/rust/pull/48125
6. https://github.com/emscripten-core/emscripten/issues/9705
7. https://blog.torproject.org/bad-exit-relays-may-june-2020