tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2024-01-10T13:32:54Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/29318Drop mingw-w64/gcc toolchain2024-01-10T13:32:54ZGeorg KoppenDrop mingw-w64/gcc toolchainThis ticket is the parent ticket for all things related to dropping the mingw-w64/gcc toolchain in favor of our new mingw-w64/clang one.This ticket is the parent ticket for all things related to dropping the mingw-w64/gcc toolchain in favor of our new mingw-w64/clang one.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/29041Compile clang closer to how Mozilla does it2023-01-05T14:13:28ZGeorg KoppenCompile clang closer to how Mozilla does itWe compile clang differently to how Mozilla does it: Mozilla has an elaborate setup with three stages (if needed) (see: https://hg.mozilla.org/releases/mozilla-esr60/file/248ca5c585f8/build/build-clang/build-clang.py) while we essentiall...We compile clang differently to how Mozilla does it: Mozilla has an elaborate setup with three stages (if needed) (see: https://hg.mozilla.org/releases/mozilla-esr60/file/248ca5c585f8/build/build-clang/build-clang.py) while we essentially "just" do what is outlined on https://clang.llvm.org/get_started.html.
We should change that and get our toolchain closer to what Mozilla provides.https://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/28830Clean up tor-browser-build build scripts/config files2023-01-05T14:13:21ZGeorg KoppenClean up tor-browser-build build scripts/config filesWe should go over the projects we have in `tor-browser-build` and clean up build scripts and config files if needed.
Areas we could/should cover:
1) We sometimes have several platform related blocks in one build script which could be c...We should go over the projects we have in `tor-browser-build` and clean up build scripts and config files if needed.
Areas we could/should cover:
1) We sometimes have several platform related blocks in one build script which could be confusing. Can we merge those (or some of them) while still keeping the overall flow of the script logic?
2) Duplicating platform-specific and !platform-specific commands, e.g. `cd $distdir` in
```
[% IF c("var/osx") %]
LIBEVENT_FILE=`basename $libeventdir/lib/libevent-*.dylib`
cd $distdir
cp bin/tor $TORBINDIR/
cd $TORBINDIR/
x86_64-apple-darwin11-install_name_tool -change $libeventdir/lib/$LIBEVENT_FILE @executable_path/$LIBEVENT_FILE tor
[% END %]
cd $distdir
```
3)...Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28811Enabling Clang's CFG for mingw-clang Windows builds2023-01-05T14:13:04ZTom Rittertom@ritter.vgEnabling Clang's CFG for mingw-clang Windows buildsWhen we're using mingw-clang, we can enable guard:cf pretty easily: https://bugzilla.mozilla.org/show_bug.cgi?id=1485016
This enforce Control Flow checks in system libraries on Windows. It is not as strong as, nor a replacement for, ena...When we're using mingw-clang, we can enable guard:cf pretty easily: https://bugzilla.mozilla.org/show_bug.cgi?id=1485016
This enforce Control Flow checks in system libraries on Windows. It is not as strong as, nor a replacement for, enabling clang's CFI checks.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28782Use Path::Tiny instead of File::Slurp in tools/clean-old and tools/dmg2mar2023-01-05T14:12:59ZboklmUse Path::Tiny instead of File::Slurp in tools/clean-old and tools/dmg2marSimilarly to legacy/trac#24361 and legacy/trac#28771, we should replace uses of File::Slurp by Path::Tiny in tools/clean-old and tools/dmg2mar.Similarly to legacy/trac#24361 and legacy/trac#28771, we should replace uses of File::Slurp by Path::Tiny in tools/clean-old and tools/dmg2mar.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28595Remove the need to update var/gradle_dependencies_version2022-08-03T12:38:51ZboklmRemove 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`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28326Tor Browser for PPC64LE2023-01-05T18:13:32ZTracTor Browser for PPC64LEI'm here to request a Tor Browser for Debian to get compiled for ppc64le architecture.
Power architecture is the only open hardware, so i think it's important for a project like Tor to support this architecture, avoiding potential backdo...I'm here to request a Tor Browser for Debian to get compiled for ppc64le architecture.
Power architecture is the only open hardware, so i think it's important for a project like Tor to support this architecture, avoiding potential backdoor on closed system.
The follow link could probably be usefull for build it correctly
https://www.talospace.com/2018/09/more-power-in-firefox-62.html
https://www.talospace.com/2018/10/patches-needed-for-firefox-63.html
If you need a ppc64le machine it will provided a cloud access for free, ask to https://twitter.com/RaptorCompSys for building and testing Tor Browser
No secure comunications is really secure on closed system, so to support an open architecture should be a priority for a project who looking for a digital freedom
**Trac**:
**Username**: power9boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28176Cleanup and add the testsuite to tor-browser-build.git2023-01-05T13:54:30ZboklmCleanup and add the testsuite to tor-browser-build.gitCurrently we have a Tor Browser testsuite in a separate git repository, at https://gitweb.torproject.org/user/boklm/tor-browser-bundle-testsuite.git/.
Rather than using a separate repository, I think it might be better to integrate that...Currently we have a Tor Browser testsuite in a separate git repository, at https://gitweb.torproject.org/user/boklm/tor-browser-bundle-testsuite.git/.
Rather than using a separate repository, I think it might be better to integrate that testsuite directly into `tor-browser-build.git`, as a sub-directory:
- quite often some Tor Browser changes need corresponding changes in the testsuite. Having both in the same repository would make it possible to do both changes with the same commit (although we might still need two commits when the change is in `tor-browser.git`), and use the same review process.
- some people don't know that we have a testsuite, or where it is. Having it in the same repository would make it easier to find and know that it exists.
- having the testsuite in the same repository would make it easier to integrate it with the build process. For example we could add some makefile command such as `make run-testsuite-testbuild`, which would make it easier for developers to run the testsuite after doing a build.
One option would be to copy the current testsuite to some `tor-browser-build.git` sub-directory, and make necessary changes to fix it and integrate it better. However I think that over time the testsuite accumulated a lot of complexity that is not really needed. Adding the current testsuite and fixing it will probably result in adding even more complexity. I think that an other option is to do some important cleanup first and only import minimal testsuite tools, and then cleanup and import each of the tests one by one.
So I think the main two options are:
1) copy the current testsuite, fix all the tests, then try to integrate it better, and to clean it.
2) rewrite minimal testsuite tools, avoiding the complexity from the previous version, and import each test one by one after fixing and cleaning them.
To me it seems easier to re-start from a minimal testsuite and re-add the needed features and tests (sometimes copying them from the old testsuite, and sometimes re-writting them from scratch if it makes more sense) than taking the current testsuite and trying to clean it little by little, so I think option 2) is better.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28175Add commands to upload bundles to virustotal2023-10-12T11:53:09ZboklmAdd commands to upload bundles to virustotalWith each new release, some users are complaining that their Windows antivirus is detecting Tor Browser as a virus. A theory is that the antivirus is blocking programs that they have not seen before until they are a few days old.
To avo...With each new release, some users are complaining that their Windows antivirus is detecting Tor Browser as a virus. A theory is that the antivirus is blocking programs that they have not seen before until they are a few days old.
To avoid this problem (or at least try to limit the duration of the problem), we could upload the Windows bundles to virustotal.com as soon as we have a build ready, so that the antivirus have seen them a few days/hours before the release.
In the past we had something as part of the testsuite uploading the bundles to virustotal, but it is currently broken and needs to be fixed. I think we could add some makefile commands to `tor-browser-build.git` such as `make upload-unsigned-build-virustotal-release` (with `*-signed-*` and `*-alpha` variants) to upload a build to virustotal (in addition to having it done by the testsuite, probably using the same script for both).https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28102Make sure we pick the exact same compile environment for Tor Browser builds2023-01-05T13:55:23ZGeorg KoppenMake sure we pick the exact same compile environment for Tor Browser buildsWhen creating a container image at time t and creating a container image at time t1 it is not guaranteed that we include the same compiler versions etc.
This has led to `mar` executables being different, for instance (see: comment:52:ti...When creating a container image at time t and creating a container image at time t1 it is not guaranteed that we include the same compiler versions etc.
This has led to `mar` executables being different, for instance (see: comment:52:ticket:26475): GCC version was in both cases 4.9.2 but in one of them contained an updated resulting in `GCC: (Debian 4.9.2-10+deb8u1) 4.9.2` as a version string instead of `GCC: (Debian 4.9.2-10) 4.9.2`.
We could fix that by making sure we compile our own GCC for this case but there might be other packages lurking with the same trouble potential. We should make sure instead that everyone creating *and* using a container image is getting/having the same available.boklmboklmhttps://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/27045Add option for firefox incremental builds2023-01-05T14:11:50ZboklmAdd option for firefox incremental buildsIn Tor Browser builds, when we need to rebuild firefox, we do a full firefox rebuild. During the development of firefox patches it would be useful to be able to do incremental rebuilds of firefox.
To do that, we could add a new makefile...In Tor Browser builds, when we need to rebuild firefox, we do a full firefox rebuild. During the development of firefox patches it would be useful to be able to do incremental rebuilds of firefox.
To do that, we could add a new makefile target for this type of build and an option in `rbm.local.conf` pointing to the firefox sources directory. We would then mount that directory in the build container and use it instead of the sources from git.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/40540Guard against failures during MAR file generation2023-01-05T14:22:07ZGeorg KoppenGuard against failures during MAR file generationWe tried to guard against errors during the MAR file generation by using `set -e` in the respective scripts but that is not working our particularly well as those scripts are using bash errors as features (see: legacy/trac#26216). We sho...We tried to guard against errors during the MAR file generation by using `set -e` in the respective scripts but that is not working our particularly well as those scripts are using bash errors as features (see: legacy/trac#26216). We should think about a better way to achieve what we want.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/26408Make MAR signature checks clearer when creating incremental MAR files2023-11-30T11:23:52ZGeorg KoppenMake MAR signature checks clearer when creating incremental MAR filesWe have
```
# bug 26054: make sure previous macOS version is code signed
if (($os eq 'osx64') && ! -f "$tmpdir/A/Contents/_CodeSignature/CodeResources") {
exit_error "Missing code signature in $from_version while creating...We have
```
# bug 26054: make sure previous macOS version is code signed
if (($os eq 'osx64') && ! -f "$tmpdir/A/Contents/_CodeSignature/CodeResources") {
exit_error "Missing code signature in $from_version while creating $mar_file";
}
if ($ENV{CHECK_CODESIGNATURE_EXISTS}) {
unless (-f "$tmpdir/A/Contents/_CodeSignature/CodeResources"
&& -f "$tmpdir/B/Contents/_CodeSignature/CodeResources") {
exit_error "Missing code signature while creating $mar_file";
}
}
```
checking twice whether essentially osx64 MAR files are signed. We should simplify that and be more verbose about why we are doing that and what the differences between both checks are. Otherwise this is easily confusing.
For simplification, I guess we don't need two separate if-clauses, rather the `CHECK_CODESIGNATURE_EXISTS` one could be part of the first one, just checking for `$tmpdir/B/Contents/_CodeSignature/CodeResources` (as the first condition is already taken care of by the first if-clause).https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/26302Build fonts we ship from source2023-01-05T13:12:01ZGeorg KoppenBuild fonts we ship from sourceIn comment:12:ticket:18364 vegansalad mentioned that there are ways to build at least some fonts from source using `fonttools` and `nototools`. Might be worth investigating how far we'd come with that.In comment:12:ticket:18364 vegansalad mentioned that there are ways to build at least some fonts from source using `fonttools` and `nototools`. Might be worth investigating how far we'd come with that.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/26115Think about using --enable-hardening for Firefox where applicable and clean u...2023-01-05T12:46:22ZGeorg KoppenThink about using --enable-hardening for Firefox where applicable and clean up our Windows wrapper scriptshttps://bugzilla.mozilla.org/show_bug.cgi?id=1418052 and https://bugzilla.mozilla.org/show_bug.cgi?id=1360299 sets hardening options we want to have, too. We should probably switch to them where applicable and clean-up our Windows wrappe...https://bugzilla.mozilla.org/show_bug.cgi?id=1418052 and https://bugzilla.mozilla.org/show_bug.cgi?id=1360299 sets hardening options we want to have, too. We should probably switch to them where applicable and clean-up our Windows wrapper scripts.https://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/25835Move build dependencies from people.tpo2023-02-20T16:03:08ZboklmMove build dependencies from people.tpoCurrently we are hosting some of the dependencies we use for building Tor Browser on people.torproject.org. However people.torproject.org is just one host, and it is sometimes down.
I think we could maybe move those files to extra.torpr...Currently we are hosting some of the dependencies we use for building Tor Browser on people.torproject.org. However people.torproject.org is just one host, and it is sometimes down.
I think we could maybe move those files to extra.torproject.org, dist.torproject.org, or ask tpa to create a new hostname for those files.