tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-09-18T19:37:05Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40945Generalize tbb-nightly in the version string2023-09-18T19:37:05ZPier Angelo VendrameGeneralize tbb-nightly in the version stringCurrently, we do something in `rbm.conf` to use `tbb-nightly` as a prefix for the version.
We use it also for base browser.
However, we might want to generalize it to something else.
So, we might need to use a prefix, or generalize on a...Currently, we do something in `rbm.conf` to use `tbb-nightly` as a prefix for the version.
We use it also for base browser.
However, we might want to generalize it to something else.
So, we might need to use a prefix, or generalize on a regex such as `[a-z]+-nightly`.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40926Make use of the Drone CI public GPG key for Mullvad Browser sha256sum verific...2023-11-02T10:47:48ZjbjorkangMake use of the Drone CI public GPG key for Mullvad Browser sha256sum verificationThe GPG public key for Drone, [located here](https://se-got-releases-001.devmole.eu/hashes/public-keys/) should be used in place of any other public GPG keys for verification of the hashes uploaded.The GPG public key for Drone, [located here](https://se-got-releases-001.devmole.eu/hashes/public-keys/) should be used in place of any other public GPG keys for verification of the hashes uploaded.boklmboklmhttps://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/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/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/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/40825Try SOURCE_DATE_EPOCH in nsis2023-03-29T17:15:53ZPier Angelo VendrameTry SOURCE_DATE_EPOCH in nsisI've tried to upstream the `--no-insert-timestamp` patch we use to make NSIS reproducible.
However, I've been answered to use `SOURCE_DATE_EPOCH`, instead (added in NSIS 3.06.1).
We could try that, and drop our patch if it works.I've tried to upstream the `--no-insert-timestamp` patch we use to make NSIS reproducible.
However, I've been answered to use `SOURCE_DATE_EPOCH`, instead (added in NSIS 3.06.1).
We could try that, and drop our patch if it works.https://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/40815Include platform details in some artifact filenames2024-01-10T08:30:59ZPier Angelo VendrameInclude platform details in some artifact filenamesSome artifacts are tied to a certain platform (e.g., Mingw, Rust, etc).
Sometimes knowing it at a glance could be useful (e.g., when reusing these artifacts outside tor-browser-build, e.g., to create a container for local incremental bu...Some artifacts are tied to a certain platform (e.g., Mingw, Rust, etc).
Sometimes knowing it at a glance could be useful (e.g., when reusing these artifacts outside tor-browser-build, e.g., to create a container for local incremental builds).
We could do that when updating the toolchains for the next ESR.
List of artifacts to fix:
- [x] ~~`mingw-w64-clang`~~ -> switched to single package for both 32-bit and 64-bit
- [x] Rust
- [ ] Binutilshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40803Force-disable parts of wasi-libc built with -mbulk-memory (port Mozilla Bug 1...2023-03-29T17:16:55ZPier Angelo VendrameForce-disable parts of wasi-libc built with -mbulk-memory (port Mozilla Bug 1773200)While I was checking for the frequency Mozilla updates the wasi-sdk with, I've noticed that they added a compilation flag to the WASI sysroot in [Bug 1773200](https://bugzilla.mozilla.org/show_bug.cgi?id=1773200).
Our script is based on...While I was checking for the frequency Mozilla updates the wasi-sdk with, I've noticed that they added a compilation flag to the WASI sysroot in [Bug 1773200](https://bugzilla.mozilla.org/show_bug.cgi?id=1773200).
Our script is based on Mozilla's, so we will likely want to add that flag to our script, too, when switching to 115.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40799Remove legacy locale iteration in build and signing scripts2023-02-28T14:26:19ZrichardRemove legacy locale iteration in build and signing scriptsWith the 12.0 Tor Browser series we no longer have one build per locale and instead package all supported language packs into one package.
However, we have a fair bit of legacy iterations over locales in our build and signing scripts wh...With the 12.0 Tor Browser series we no longer have one build per locale and instead package all supported language packs into one package.
However, we have a fair bit of legacy iterations over locales in our build and signing scripts which we technically no longer need, since we now have one `ALL` locale.
We should probably do a pass an clean up the scripts and remove the now unnecessary iterations.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40785Add some step in the signing process to check that we have two matching builds2023-11-01T19:18:10ZboklmAdd some step in the signing process to check that we have two matching buildsChecking that we have two matching builds currently needs to be done manually before starting the signing process.
We can add add some step in the signing process to check that `sha256sums-unsigned-build.txt` has been signed by two people.Checking that we have two matching builds currently needs to be done manually before starting the signing process.
We can add add some step in the signing process to check that `sha256sums-unsigned-build.txt` has been signed by two people.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40749Create a project for libstd++2024-02-13T13:31:10ZPier Angelo VendrameCreate a project for libstd++We need the modern `libstdc++` from GCC in some containers that otherwise wouldn't need the compiler.
So far, we've copied it to some outputs if we knew we needed it (`tor` and `rust`), or we included the compiler on Linux only to set t...We need the modern `libstdc++` from GCC in some containers that otherwise wouldn't need the compiler.
So far, we've copied it to some outputs if we knew we needed it (`tor` and `rust`), or we included the compiler on Linux only to set the proper `LD_LIBRARY_PATH` (`wasi-sysroot`).
Notice that in `tor` we copy it only to then copy it to tor-browser.
Also, if we end up doing anything for the browser project, we have to be careful, as we might break the updater (tor-browser#13359).https://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/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/40726Remove BINDGEN_CFLAGS on Windows2023-06-01T16:35:28ZcypherpunksRemove BINDGEN_CFLAGS on WindowsYou don't need it anymore.
https://phabricator.services.mozilla.com/D125636You don't need it anymore.
https://phabricator.services.mozilla.com/D125636https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40722Create installer icon for base-browser2023-02-03T12:01:27ZrichardCreate installer icon for base-browser@duncan this is incredibly low priority but something that should be done at some point. We're currently using the Tor Browser icon for base-browser, so we need to swap it out with something nice and generic and not Tor Browser.@duncan this is incredibly low priority but something that should be done at some point. We're currently using the Tor Browser icon for base-browser, so we need to swap it out with something nice and generic and not Tor Browser.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40721Replace base-browser NSIS installer icon2022-12-22T11:17:21ZrichardReplace base-browser NSIS installer iconWe're currently using a copy of the tor-browser installer icon so we should swap it out to avoid confusion.We're currently using a copy of the tor-browser installer icon so we should swap it out to avoid confusion.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40710Provide the Tor Expert Bundle for Windows as a *.zip archive2023-04-03T12:47:53Zcomputer_freakProvide the Tor Expert Bundle for Windows as a *.zip archiveThe [Expert Bundle](https://www.torproject.org/download/tor/) for Windows prior to Tor Browser 12.0 was a `*.zip` archive.\
Now it's a `*.tar.gz` archive.
Native Windows can unpack `*.zip` archives but doesn't know what to do with `.tar...The [Expert Bundle](https://www.torproject.org/download/tor/) for Windows prior to Tor Browser 12.0 was a `*.zip` archive.\
Now it's a `*.tar.gz` archive.
Native Windows can unpack `*.zip` archives but doesn't know what to do with `.tar.gz`.