tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-08-25T23:13:34Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40611Audit license and copyright info2023-08-25T23:13:34ZrichardAudit license and copyright infoHTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)HTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40571Windows copyright notices should contain Tor Project2023-08-25T23:13:38ZMark SmithWindows copyright notices should contain Tor ProjectWhile working on legacy/trac#16910, Kathy and I noticed that the copyright notices embedded within the browser executables on Windows (firefox.exe, updater.exe) have the same text as in Firefox. For consistency with Mac OS, we should use...While working on legacy/trac#16910, Kathy and I noticed that the copyright notices embedded within the browser executables on Windows (firefox.exe, updater.exe) have the same text as in Firefox. For consistency with Mac OS, we should use text like:
Copyright 2015 The Tor Project
or maybe we should change both platforms to use:
Copyright (c) 2015, The Tor Project, Inc.
For reference, the file Bundle-Data/Docs/Licenses/Tor.txt within our builders/tor-browser-bundle repo. contains the following copyright text:
Copyright (c) 2001-2004, Roger Dingledine
Copyright (c) 2004-2006, Roger Dingledine, Nick Mathewson
Copyright (c) 2007-2013, The Tor Project, Inc.
(we we are at it, we should also update the year there).Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/25863Check where the -mwindows flag is needed2023-01-05T12:42:49ZboklmCheck where the -mwindows flag is neededCurrently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really nee...Currently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really needed, and only set it there.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40642statically-link dependencies into tor daemon2023-07-18T21:40:35Zrichardstatically-link dependencies into tor daemonWe ship our own versions of libevent, openssl, etc with tor in Tor Browser. This can cause issues when systems do not use these packaged libraries ( like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41336 ).
We...We ship our own versions of libevent, openssl, etc with tor in Tor Browser. This can cause issues when systems do not use these packaged libraries ( like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41336 ).
We should statically link our dependencies into the tor daemon. This will ensure we are actually, using the implementation we think we are, and it should reduce the final package/install size as LTO will ensure we are only building and linking in the symbols actually used.
Ricochet-Refresh builds openssl, zlib and libevent this way for tor on Windows (x86,x64), Linux (x86,x64), and macOS (x64):
- openssl: https://github.com/blueprint-freespeech/ricochet-build/tree/main/projects/openssl
- libvent: https://github.com/blueprint-freespeech/ricochet-build/tree/main/projects/libevent
- zlib: https://github.com/blueprint-freespeech/ricochet-build/tree/main/projects/zlib
- tor: https://github.com/blueprint-freespeech/ricochet-build/tree/main/projects/tor
Android is not currently built/supported so anything in there referncing it is left-overs from the original tor-browser-build fork.Marco SimonelliMarco Simonellihttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40579Check for `file` command in Tor Browser start script before using it2022-07-13T23:34:14ZGeorg KoppenCheck for `file` command in Tor Browser start script before using itIn `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-...In `start-tor-browser` we do
```
SYSARCHITECTURE=$(getconf LONG_BIT)
TORARCHITECTURE=$(expr "$(file TorBrowser/Tor/tor)" : '.*ELF \([[:digit:]]*\)')
if [ $SYSARCHITECTURE -ne $TORARCHITECTURE ]; then
complain "Wrong architecture? 32-bit vs. 64-bit."
exit 1
fi
```
to bail out early in case users have downloaded a bundle for the wrong architecture. Now, it turns out that there are Linux distros out there (NixOS seems to be one of those) that don't find `file` that way. A fix for that would be to check for the existence of `file` and if we can't find it to note that we assume the user knows what they are doing and proceed anyway.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40578Add README to Tor Browser2023-01-05T14:22:24ZtraumschuleAdd README to Tor BrowserI am struck that there is none.
```
tor-browser8.5a1$ find |grep -i readme
./Browser/TorBrowser/Docs/Obfsproxy/README
./Browser/TorBrowser/Docs/fteproxy/README.md
./Browser/TorBrowser/Docs/meek/README
./Browser/TorBrowser/Docs/libfte/RE...I am struck that there is none.
```
tor-browser8.5a1$ find |grep -i readme
./Browser/TorBrowser/Docs/Obfsproxy/README
./Browser/TorBrowser/Docs/fteproxy/README.md
./Browser/TorBrowser/Docs/meek/README
./Browser/TorBrowser/Docs/libfte/README.md
./Browser/TorBrowser/Docs/snowflake/README.md
```https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40565Potential Wayland dependency2022-10-08T02:54:47ZMatthew FinkelPotential Wayland dependencyWe received a report that Tor Browser 11.0 now fails to start on a (Gentoo) Linux machine that does not have Wayland installed. Firefox 91.3.0esr does start.
`libxul.so: undefined symbol: gdk_wayland_display_get_wl_compositor`We received a report that Tor Browser 11.0 now fails to start on a (Gentoo) Linux machine that does not have Wayland installed. Firefox 91.3.0esr does start.
`libxul.so: undefined symbol: gdk_wayland_display_get_wl_compositor`boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40551Upstream go and gomobile patches2023-01-05T13:54:39ZboklmUpstream go and gomobile patchesIn commit eee5d30a9ab1d727caac262cb62f72aaab75e0a0, we are adding one go patch, and one gomobile patch, in order to fix reproducibility issues.
We should try to upstream those patches.In commit eee5d30a9ab1d727caac262cb62f72aaab75e0a0, we are adding one go patch, and one gomobile patch, in order to fix reproducibility issues.
We should try to upstream those patches.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40541`about:buildconfig` is missing configure options2023-01-05T14:22:16ZGeorg Koppen`about:buildconfig` is missing configure optionsFor some reason we are missing some configure options in `about:buildconfig` when building Tor Browser. On Windows e.g. --disable-stylo and --disable-jemalloc. This got reported on the blog (https://blog.torproject.org/comment/276031#com...For some reason we are missing some configure options in `about:buildconfig` when building Tor Browser. On Windows e.g. --disable-stylo and --disable-jemalloc. This got reported on the blog (https://blog.torproject.org/comment/276031#comment-276031)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34203Some of the static libraries we build are not reproducible2023-01-05T14:34:24ZGeorg KoppenSome of the static libraries we build are not reproducibleI just realized that the `.a` archives we create (e.g.) for `libevent` on android are not reproducible while their contents are. We should fix that as it makes it easier to compare results and spot problems.
While we are at it we should...I just realized that the `.a` archives we create (e.g.) for `libevent` on android are not reproducible while their contents are. We should fix that as it makes it easier to compare results and spot problems.
While we are at it we should check other outputs as well as I bet not only `lilbevent` is affected.
FWIW: In the `libevent` case it seems timestamps play a role when creating the `.a` files.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32200only include required bits of OpenSSL in Android builds2022-10-06T01:19:52Zeighthaveonly include required bits of OpenSSL in Android buildsI've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./...I've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./Configure \
no-comp no-dtls no-ec2m no-psk no-srp no-ssl2 no-ssl3 \
no-camellia no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc4 no-rc5 no-rmd160 no-whirlpool \
no-dso no-engine no-hw no-ui-console \
no-shared no-unit-test \
```
The open question is whether the test coverage is good enough to know whether this breaks anything.
Additionally, I think Android _ndk-build_ used to 'gcc' "gc sections" to mark unused code blocks which were then stripped out at the end. They seemed to have stopped doing this with _clang_, but I don't know why. In the past, I have seen the "gc sections" stripping reduce binary size quite a bit.
Also related: I tried building with `-Os` and `-Oz` instead of `-O2`. That made a big difference:
https://github.com/guardianproject/tor-android/issues/18
This is related to legacy/trac#28764https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/31581KDE Desktop file error2022-10-06T01:19:17ZTracKDE Desktop file errorThe freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix...The freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix, replace the end of the Exec command with "\\" which escapes the bash continuation char.
Tor v8.5.4
**Trac**:
**Username**: Psnarfhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22633Running ./start-tor-browser.desktop --detach --log creates two log files2022-08-03T14:52:38ZGeorg KoppenRunning ./start-tor-browser.desktop --detach --log creates two log filesAdding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://bl...Adding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://blog.torproject.org/comment/269202#comment-269157.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/19181Firefox >= 48 ships with an ICU pre-compiled blob2023-01-05T14:10:02ZGeorg KoppenFirefox >= 48 ships with an ICU pre-compiled blobIn https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-co...In https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-compilation scenario. We should investigate whether we want to ship that blob.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18130Fold in pre 3.0 Tor Browser changelogs2023-02-09T09:50:44ZGeorg KoppenFold in pre 3.0 Tor Browser changelogsWe should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the for...We should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the format we use today, but it's worthwhile.