Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:25:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32200only include required bits of OpenSSL in Android builds2020-06-16T01:25:49Zeighthaveonly 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 #28764https://gitlab.torproject.org/legacy/trac/-/issues/20135OSX: fail during bundling if any symlinks are used2020-06-16T01:24:48ZMark SmithOSX: fail during bundling if any symlinks are usedIn #19410, mcs said: Regarding the symlink issue, as a failsafe we could check to make sure no symlinks are used, but we would need to do that as we create the dmg.In #19410, mcs said: Regarding the symlink issue, as a failsafe we could check to make sure no symlinks are used, but we would need to do that as we create the dmg.https://gitlab.torproject.org/legacy/trac/-/issues/2340protect users against freeze, replay and version-rollback attacks2020-06-16T01:24:29ZRobert Ransomprotect users against freeze, replay and version-rollback attacksCurrently, [we tell users](https://www.torproject.org/docs/verifying-signatures) that the GPG signatures linked to from the download page 'allow you to verify the file you've downloaded is exactly the one that we intended you to get. For...Currently, [we tell users](https://www.torproject.org/docs/verifying-signatures) that the GPG signatures linked to from the download page 'allow you to verify the file you've downloaded is exactly the one that we intended you to get. For example, tor-browser-1.3.15_en-US.exe is accompanied by tor-browser-1.3.15_en-US.exe.asc.' This is false.
The GPG signatures only prove that a particular person associated with The Tor Project has signed a particular file; they do not authenticate the filename, thus they do not authenticate the package name or the package version, and they do not prove that a particular package file is the final build of a package version which we want to distribute to users. This leaves our users vulnerable to version-rollback attacks and package-substitution attacks if they download packages from mirrors or over non-HTTPS connections.
We should:
* switch to signing the output of `sha256sum` on a package file, which includes the filename and a hash of the file, rather than signing the package file directly, and
* explain on the verifying-signatures page how to verify downloaded packages using the signed SHA256SUM files, including explaining that unless there is a blank line after the '`Hash: `' line and before the hash-and-filename lines, the SHA256SUM file has been tampered with.https://gitlab.torproject.org/legacy/trac/-/issues/33953Provide a way for easily updating Go dependencies of projects2020-06-16T01:26:16ZGeorg KoppenProvide a way for easily updating Go dependencies of projectsIn #28325 we are working on enabling `go.mod` support for our Go based projects. While that will be an improvement in that we don't need to work around a new default anymore, it does not solve the question how we can easily update all th...In #28325 we are working on enabling `go.mod` support for our Go based projects. While that will be an improvement in that we don't need to work around a new default anymore, it does not solve the question how we can easily update all the dependencies of a project and the dependencies of those dependencies. That's the scope for this ticket. Besides #28325 we should keep in mind that we might want to think about how we want to handle go modules in the future. Right now, we have a project per module in `tor-browser-build`. Maybe that's not a smart thing with the growing amount of projects we have. Either way, the solution for this ticket will have an impact on that, so we should take the question about how to handle the module-project relationship into account.
For the dependency update path forward we a bunch of possible options, some already mentioned in #28325 (in no particular order):
1) Use `go mod vendor` to vendor in the dependencies and then build with `-mod=vendor` to use the `vendor` folder with the dependencies.
2) Refine the `gomodtorbm` script written by dcf/cohosh (see: #28942 and #33576)
3) Use `go mod download` to fetch dependencies into the cache and then point, during the build, with `GOPROXY` to the cached files (that's feeling similar to what we use for our Gradle dependencies right now).
There might be more than those three.
boklm had a nice idea of restructuring our go projects in a way that we'd only have one `go-module` project and we could list all needed dependencies directly in the respective project under `input_files` (see: comment:42:ticket:28942). That might be orthogonal to 1) and 3) but might actually help with 2). not sure.https://gitlab.torproject.org/legacy/trac/-/issues/32649Provide one place for setting the Firefox build we use2020-06-16T01:25:56ZGeorg KoppenProvide one place for setting the Firefox build we useWe set `ff_build` both in the config files for `firefox-locale-bundle` and `firefox-langpacks`. This is error-prone and we should have one canoncial place for it.We set `ff_build` both in the config files for `firefox-locale-bundle` and `firefox-langpacks`. This is error-prone and we should have one canoncial place for it.https://gitlab.torproject.org/legacy/trac/-/issues/13890Provide support for urdu language in Tor Browser2020-06-16T01:24:40ZArturo FilastòProvide support for urdu language in Tor BrowserCurrently Tor Browser does not support the urdu language.
Implementing this feature, though, is blocking on having an ESR of Firefox that supports such language, that will probably not happen before August 2015.
Support for urdu in Fir...Currently Tor Browser does not support the urdu language.
Implementing this feature, though, is blocking on having an ESR of Firefox that supports such language, that will probably not happen before August 2015.
Support for urdu in Firefox was just recently announced: http://mozilla-pakistan.org/2014/05/12/new-firefox-launch-event-pakistan/ and xpi's for it are only shipped in their alpha builds: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/mac/xpi/.
When that is done the TorButton and TorLauncher components would need to be translated.
It's probably a good idea to implement this as part of #12967.https://gitlab.torproject.org/legacy/trac/-/issues/31864Provide Tor Browser for Windows arm642020-06-16T01:25:45ZGeorg KoppenProvide Tor Browser for Windows arm64Firefox for Windows on arm64 is a [tier 1 platform for Mozilla](https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations) and respectively supported. It's available with our switch to ESR 68 and we should look into...Firefox for Windows on arm64 is a [tier 1 platform for Mozilla](https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations) and respectively supported. It's available with our switch to ESR 68 and we should look into providing a Tor Browser for it, too.https://gitlab.torproject.org/legacy/trac/-/issues/34391Remove --enable-signmar from .mozconfig files2020-06-16T01:26:33ZGeorg KoppenRemove --enable-signmar from .mozconfig filesSince https://bugzilla.mozilla.org/show_bug.cgi?id=1562952 landed there is no `--enable-signmar` anymore. We should remove it from our Linux .mozconfig files.Since https://bugzilla.mozilla.org/show_bug.cgi?id=1562952 landed there is no `--enable-signmar` anymore. We should remove it from our Linux .mozconfig files.https://gitlab.torproject.org/legacy/trac/-/issues/31992Remove apktool workaround in #315642020-06-16T01:25:47ZGeorg KoppenRemove apktool workaround in #31564We found a reproducibility issue on Android with the switch to Firefox 68 ESR and the respective toolchain and fixed it by using an `apktool` downloaded from the Internet. We should remove that workaronud and replace it with a better one...We found a reproducibility issue on Android with the switch to Firefox 68 ESR and the respective toolchain and fixed it by using an `apktool` downloaded from the Internet. We should remove that workaronud and replace it with a better one (e.g. by switching our compile environment to Debian Buster and using the means the distro provides us with).Shane IsbellShane Isbellhttps://gitlab.torproject.org/legacy/trac/-/issues/28595Remove the need to update var/gradle_dependencies_version2020-06-16T01:25:23ZboklmRemove the need to update var/gradle_dependencies_versionCurrently we need to update `var/gradle_dependencies_version` each time `gradle-dependencies-list.txt` is updated.
If you change `gradle-dependencies-list.txt` without updating `var/gradle_dependencies_version`, then you can easily end ...Currently we need to update `var/gradle_dependencies_version` each time `gradle-dependencies-list.txt` is updated.
If you change `gradle-dependencies-list.txt` without updating `var/gradle_dependencies_version`, then you can easily end up with the wrong list of gradle dependencies being used in a build.
To avoid this we should see if we can make the gradle dependencies be fetched again automatically when `gradle-dependencies-list.txt` has been updated, without the need to update `var/gradle_dependencies_version`.https://gitlab.torproject.org/legacy/trac/-/issues/34434Remove unused $var: 1 declarations in rbm.conf2020-06-16T01:26:35ZGeorg KoppenRemove unused $var: 1 declarations in rbm.confThere are a bunch of unused $var: 1 declarations in `rbm.conf` (that is they don't have a matching `[% c("var/$var") %]` check). We should clean that up and keep things tidy so that it is obvious where things need to get added and where ...There are a bunch of unused $var: 1 declarations in `rbm.conf` (that is they don't have a matching `[% c("var/$var") %]` check). We should clean that up and keep things tidy so that it is obvious where things need to get added and where they are not needed.https://gitlab.torproject.org/legacy/trac/-/issues/23045Replace *.tlb with our own during build time2020-06-16T01:24:57ZGeorg KoppenReplace *.tlb with our own during build timemingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get ri...mingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get rid of the ones in the repo and build them ourselves.https://gitlab.torproject.org/legacy/trac/-/issues/20322SafeSEH support for mingw-w64 for Tor Browser on Windows2020-06-16T01:24:50ZbugzillaSafeSEH support for mingw-w64 for Tor Browser on WindowsNot only SEH, because of www.fuzzysecurity.com/tutorials/expDev/3.html
Even YASM can do it https://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.htmlNot only SEH, because of www.fuzzysecurity.com/tutorials/expDev/3.html
Even YASM can do it https://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/18867Ship auto-updates for Tor Browser nightly channel2020-06-16T01:24:47ZGeorg KoppenShip auto-updates for Tor Browser nightly channelWe want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.We want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.https://gitlab.torproject.org/legacy/trac/-/issues/28124Show Tor Browser icon as macOS volume icon2020-06-16T01:25:18ZGeorg KoppenShow Tor Browser icon as macOS volume iconIIRC we show the generic volume icon on macOS instead of the Tor Browser one. We should try to show ours instead, though. It seems Mozills did this within their cross-compilation setup a while back (https://bugzilla.mozilla.org/show_bug....IIRC we show the generic volume icon on macOS instead of the Tor Browser one. We should try to show ours instead, though. It seems Mozills did this within their cross-compilation setup a while back (https://bugzilla.mozilla.org/show_bug.cgi?id=1197325) and we might benefit fromt that work.https://gitlab.torproject.org/legacy/trac/-/issues/34046Sign commits with gpg2020-06-16T01:26:22ZboklmSign commits with gpgAs discussed in ticket:25102#comment:20, we should sign all top commits from branches that are used in nightly builds.As discussed in ticket:25102#comment:20, we should sign all top commits from branches that are used in nightly builds.https://gitlab.torproject.org/legacy/trac/-/issues/29815Sign our macOS bundles on Linux2020-06-16T01:25:32ZGeorg KoppenSign our macOS bundles on LinuxI've wanted that for a long time and did not find an already open ticket, but we should leverage our hardened Linux box to sign our .dmg files as well, like we do for our .exe files. One part that makes it harder as the macOS signing is ...I've wanted that for a long time and did not find an already open ticket, but we should leverage our hardened Linux box to sign our .dmg files as well, like we do for our .exe files. One part that makes it harder as the macOS signing is content signing while the authenticode signing is not. Another hard part is that there is no such thing as `osslsigncode` which we could use with (minimal) patching.
Or maybe there is? See: https://github.com/saucelabs/isign. However, there is still (much) work to do, see: https://github.com/saucelabs/isign/issues/88.https://gitlab.torproject.org/legacy/trac/-/issues/31517Simplify macOS related bits in Firefox project2020-06-16T01:25:38ZGeorg KoppenSimplify macOS related bits in Firefox project#30323 included already simplifications made in https://bugzilla.mozilla.org/show_bug.cgi?id=1513798 but not all of them due to breakage. We should follow-up on that and bring our compile instructions closer to what Mozilla is deploying.#30323 included already simplifications made in https://bugzilla.mozilla.org/show_bug.cgi?id=1513798 but not all of them due to breakage. We should follow-up on that and bring our compile instructions closer to what Mozilla is deploying.https://gitlab.torproject.org/legacy/trac/-/issues/34203Some of the static libraries we build are not reproducible2020-06-16T01:26:26ZGeorg 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/legacy/trac/-/issues/5184Spanish TBB contains all Torbutton and Tor Launcher locale files2020-06-16T01:24:30ZRobert RansomSpanish TBB contains all Torbutton and Tor Launcher locale files(Presumably the English TBB contains all of Torbutton's locale files, too.)
Surely we don't need to ship _all_ Torbutton locale files in _all_ TBBs. I wonder how much they enlarge the tarball -- if they're worth shipping, they should b...(Presumably the English TBB contains all of Torbutton's locale files, too.)
Surely we don't need to ship _all_ Torbutton locale files in _all_ TBBs. I wonder how much they enlarge the tarball -- if they're worth shipping, they should be significant.
This is a Bundle build-script issue, not a ...Button issue.