tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-08-28T16:17:12Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40700provide the list of architectures as a json2023-08-28T16:17:12Zmeskiomeskio@torproject.orgprovide the list of architectures as a jsonNow that the downloads.json is splited by architecture (#40254) it will be really useful for the consumers (like gettor) of those files to be able to retrieve the full list of architectures.Now that the downloads.json is splited by architecture (#40254) it will be really useful for the consumers (like gettor) of those files to be able to retrieve the full list of architectures.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40903Make xz multi-threaded2023-08-26T06:06:57ZboklmMake xz multi-threadedIn some parts of the build (like `projects/firefox`), we create some
`tar.xz` files. To make creating those files faster, we should enable
xz multi-threading, by setting the env variable
`XZ_OPTS=--threads=$num_procs`.
We should also ch...In some parts of the build (like `projects/firefox`), we create some
`tar.xz` files. To make creating those files faster, we should enable
xz multi-threading, by setting the env variable
`XZ_OPTS=--threads=$num_procs`.
We should also check that the archives are still reproducible when
multi-threading is enabled.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40899tor from expert bundle requires LD_LIBRARY_PATH to launch in some cases2023-08-26T06:06:53Ztrinity-1686ator from expert bundle requires LD_LIBRARY_PATH to launch in some casestoday someone reported on IRC they were unable to run tor from the expert bundle on Debian 12, despite it working on Debian 11. That person left promptly so I'm not able to confirm the issue I reproduced is exactly theirs, but it looks s...today someone reported on IRC they were unable to run tor from the expert bundle on Debian 12, despite it working on Debian 11. That person left promptly so I'm not able to confirm the issue I reproduced is exactly theirs, but it looks similar:
- On Debian 11, with a system tor installed (or the right set of libs), tor from the expert bundle starts without issues, using host libraries. If some of those libraries are missing, it fails due to the missing libraries, and needs `LD_LIBRARY_PATH=$(pwd)` to work.
- On Debian 12, tor from the expert bundle can never start without `LD_LIBRARY_PATH=$(pwd)`, as it was compiled against libssl 1.1, and Debian 12 only ever provides libssl 3, so that library is always missing.
maybe related to #13373https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40701Make GeckoView take the branch/tags from Firefox2023-08-26T06:05:48ZPier Angelo VendrameMake GeckoView take the branch/tags from FirefoxA while ago, we made GeckoView use the same branch as Firefox for desktop (tor-browser#41308).
However, we did not change the GeckoView project to use the same branch as Firefox, but we're keeping in sync always (even when we do desktop...A while ago, we made GeckoView use the same branch as Firefox for desktop (tor-browser#41308).
However, we did not change the GeckoView project to use the same branch as Firefox, but we're keeping in sync always (even when we do desktop-only changes or Android-only changes, even though the latter are definitely rarer).
We should modify GV's config to take the same branch as FF automatically.
Last nightly, for example, failed because I forgot to update the nightly has on GV.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40542Split up rbm.conf2023-08-26T06:05:20ZGeorg KoppenSplit up rbm.confThe options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.The options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.Sponsor 131 - Phase 5 - Ongoing Maintenanceboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40861Add README to update_responses to document downloads.json etc2023-08-26T05:46:31ZruihildtAdd README to update_responses to document downloads.json etcCurrently, we use the tag link using the following format for the Github release link, as follow:
`https://github.com/mullvad/mullvad-browser/releases/tag/mullvad-browser-102.11.0esr-12.0-1-build1`
This is inconvenient for:
- downstrea...Currently, we use the tag link using the following format for the Github release link, as follow:
`https://github.com/mullvad/mullvad-browser/releases/tag/mullvad-browser-102.11.0esr-12.0-1-build1`
This is inconvenient for:
- downstream packagers using the tag to download from the GitHub page new releases
- dynamically linking our changelog on our website
- generally being able to look at the release version from the link
This is why, we have changed the release tags to the following format:
`https://github.com/mullvad/mullvad-browser/releases/tag/12.0.6`
This needs to be updated when generating the XML update responses.
--------------
Additional considerations (Nice to have if trivial to add)
- For now, we're manually adding this tag to the branch pushed on Github. If this can someone get added automatically, then it's a win.
- https://cdn.mullvad.net/browser/update_responses/update_1/release/downloads.json actually contains a tag, which is not present on the branch moved to our Github repository. Could this tag be changed to the same format `XX.X.X`?
EDIT: The tag referenced in downloads.json is not self-evident as to what it is for, we should add some small documentation there for users that go looking for it.https://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/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/40819Sign macOS tor executables in tor expert bundle2023-08-22T20:10:21ZsebSign macOS tor executables in tor expert bundleI'm trying to use the tor executable and pluggable transports from the tor expert bundle while porting briar-desktop to macOS. I've seen https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40397 and thanks for creat...I'm trying to use the tor executable and pluggable transports from the tor expert bundle while porting briar-desktop to macOS. I've seen https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40397 and thanks for creating the tor expert bundle in the first place!
It looks like the `tor` executable shipped with the expert bundle is not signed. As a result, I cannot run it as a subprocess from within the JVM. I've started debugging this and it looks like it doesn't have anything to do with the way we use `ProcessBuilder` to launch the executable on the JVM (everything works fine when I use the `tor.real` executable shipped with the TorBrowser DMG package). Taking the JVM side of things out of the picture, when I try to run `./tor` from the expert bundle on the shell, I do get this:
```
zsh: killed ./tor
```
It might also show a popup notifying me about the fact that the developer of the executable cannot be verified with the options in the dialog to either move it to trash or cancel the operation.
The executable shipped in the TorBrowser DMG packages works fine however. I wasn't sure it's actually the executable itself that is signed or if the OS keeps track of the DMG it has been extracted from (which is signed itself). So I extracted the file on a Linux machine and transferred it to a macOS machine that had never seen that file or TorBrowser before. I was still able to run `tor.real` successfully there.
This makes me wonder: would it be desirable from your point of view and technically possible to sign the executables shipped with the expert bundle the same way the ones from the TorBrowser distribution are?boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40568Set up Android signing token on the signing machine2023-08-22T19:44:55ZGeorg KoppenSet up Android signing token on the signing machineSponsor 131 - Phase 4 - Browser Release Managementhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40729Update mmdepbstrap and use gpgvnoexpkeysig2023-08-22T19:43:49ZboklmUpdate mmdepbstrap and use gpgvnoexpkeysigTo replace the workaround we used in 1c5314b50ca7e002d77f3e850c300f0c85093c92 to solve the issue with expired jessie key, we can update `mmdebstrap` (to [5b0bb46421ab946457b16d271bee0db08d9174a6](https://gitlab.mister-muffin.de/josch/mmd...To replace the workaround we used in 1c5314b50ca7e002d77f3e850c300f0c85093c92 to solve the issue with expired jessie key, we can update `mmdebstrap` (to [5b0bb46421ab946457b16d271bee0db08d9174a6](https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/5b0bb46421ab946457b16d271bee0db08d9174a6) or later commit), and use `mmdebstrap --aptopt='Apt::Key::gpgvcommand "/path/to/mmdebstrap/gpgvnoexpkeysig"'`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40743Update go project to pull source from go.dev rather than golang.org2023-08-22T19:43:43ZrichardUpdate go project to pull source from go.dev rather than golang.orggolang.org redirects to go.dev now.golang.org redirects to go.dev now.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40892Move torrc-defaults, geoip and geoip6 on Windows and Linux2023-08-22T19:34:11ZPier Angelo VendrameMove torrc-defaults, geoip and geoip6 on Windows and LinuxFrom tor-browser#41868:
> Uhm I actually I remember tweaking my torrc file in the past. So I checked and I realised that I had also mistakenly edited the `torrc-defaults` file (ouch!) so it wouldn't get correctly updated! Indeed in the ...From tor-browser#41868:
> Uhm I actually I remember tweaking my torrc file in the past. So I checked and I realised that I had also mistakenly edited the `torrc-defaults` file (ouch!) so it wouldn't get correctly updated! Indeed in the update.log file I read:
>
> ```
> EXECUTE PATCH TorBrowser/Data/Tor/torrc-defaults
> LoadSourceFile: destination file size 962 does not match expected size 834
> LoadSourceFile failed
> ### execution failed
> ```
If you read on `torrc`:
```
# torrc-defaults for Tor Browser
#
# DO NOT EDIT THIS FILE
#
# This file is distributed with Tor Browser and SHOULD NOT be modified (it
# may be overwritten during the next Tor Browser update). To customize your
# Tor configuration, shut down Tor Browser and edit the torrc file.
```
So, I think that we shouldn't ship it in `Browser/TorBrowser/Data/Tor`, but in `Browser/TorBrowser/Tor`.
On macOS, we already ship these files in the app bundle.
I think this was somehow already known, because while checking I found this comment in `TorLauncherUtils.jsm`:
```js
// FIXME: Should we move this file to the tor directory, in the other
// platforms, since it is not user data?
```
When we eventually do this, we should update also that file.
The browser expects `geoip` and `geoip6` to be in the same directory as `torrc-defaults` anyway.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40548Investigate using Snaps2023-08-21T18:08:20ZMatthew FinkelInvestigate using SnapsShould we distribute Tor Browser as a snap?
https://snapcraft.io/Should we distribute Tor Browser as a snap?
https://snapcraft.io/https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40912Update mar-tools version in tools/signing/nightly/config.yml and projects/mar...2023-08-21T16:58:30ZboklmUpdate mar-tools version in tools/signing/nightly/config.yml and projects/mar-tools/configAfter a version including #40829 has been released (changing the
filename of mar-tools zip), we should update the `martools_version` in
`tools/signing/nightly/config.yml`, and checkout the new commit on
`tbb-nightlies-master.torproject.o...After a version including #40829 has been released (changing the
filename of mar-tools zip), we should update the `martools_version` in
`tools/signing/nightly/config.yml`, and checkout the new commit on
`tbb-nightlies-master.torproject.org`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40596Consider switching from Gzip to Zstandard for artifacts2023-07-20T14:28:37ZPier Angelo VendrameConsider switching from Gzip to Zstandard for artifactsWe could check if using zstd could make builds shorter basically for free.We could check if using zstd could make builds shorter basically for free.Sponsor 131 - Phase 5 - Ongoing Maintenanceboklmboklmhttps://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/13373Get rid of LD_LIBRARY_PATH and use a relative RPATH/RUNPATH in Linux bundles2023-07-18T17:16:04ZGeorg KoppenGet rid of LD_LIBRARY_PATH and use a relative RPATH/RUNPATH in Linux bundlesRelying on LD_LIBRARY_PATH in our start script can cause all sorts of pain (see legacy/trac#13359 for an example). We should take the cleaner approach to compile the binaries that need it with a relative RPATH/RUNPATH and get rid of LD_L...Relying on LD_LIBRARY_PATH in our start script can cause all sorts of pain (see legacy/trac#13359 for an example). We should take the cleaner approach to compile the binaries that need it with a relative RPATH/RUNPATH and get rid of LD_LIBRARY_PATH. We need to adapt our tests as well to make the pass if a RPATH/RUNPATH with ${ORIGIN} is showing up.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40056Get all mobile dependencies during dry run2023-07-17T12:52:26ZGeorg KoppenGet all mobile dependencies during dry runThe first build after a version bump is usually with networking allowed
to get all the Gradle dependencies extracted. That step is currently
failing for `application-services`, `android-components`, and `fenix` for unknown reasons: the G...The first build after a version bump is usually with networking allowed
to get all the Gradle dependencies extracted. That step is currently
failing for `application-services`, `android-components`, and `fenix` for unknown reasons: the Gradle
`--debug` output does not show artifact downloads for some dependencies
for later re-use in our mavenLocal setup.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40202Use constant placeholder for pom file instead of file hash2023-07-12T14:09:09ZMatthew FinkelUse constant placeholder for pom file instead of file hashIn #40163 we stopped comparing the hash of the pom files. We should stop including it entirely and use a placeholder instead. This will make comparing modifications easier.In #40163 we stopped comparing the hash of the pom files. We should stop including it entirely and use a placeholder instead. This will make comparing modifications easier.