tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-11-02T07:25:49Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34398Harden our code signing on macOS2023-11-02T07:25:49ZGeorg KoppenHarden our code signing on macOSWhile legacy/trac#32506 might be not doable during our transition to ESR 78 we might be able to pick up some improvements nevertheless, see:
https://hg.mozilla.org/releases/mozilla-beta/rev/497690887467ccf0709d71fdb1b20d0647388df9While legacy/trac#32506 might be not doable during our transition to ESR 78 we might be able to pick up some improvements nevertheless, see:
https://hg.mozilla.org/releases/mozilla-beta/rev/497690887467ccf0709d71fdb1b20d0647388df9https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34368Improve authenticode-signing script to better check for a signature2023-11-01T19:18:57ZGeorg KoppenImprove authenticode-signing script to better check for a signatureOur current `authenticode-signing.sh` script checks two things at the moment:
1) Whether a .exe is still unsigned
2) Whether removing a signature (using `osslsigncode remove-signature`) is producing the same SHA-256 sum as outlined in t...Our current `authenticode-signing.sh` script checks two things at the moment:
1) Whether a .exe is still unsigned
2) Whether removing a signature (using `osslsigncode remove-signature`) is producing the same SHA-256 sum as outlined in the SHA-256 sums file.
If both conditions hold it concludes that the bundles are properly signed.
There are ways for improvement here. While I think it's important to check that removing the signature provides the expected unsigned SHA-256 we could try to check the signature directly.
`osslsigncode verify -require-leaf-hash` comes to mind. We should investigate, though, how that behaves in case of truncated/broken signatures or no signatures at all.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34356Consider bundling Python binary on GNU/Linux2023-01-05T15:02:07ZJeremyRandConsider bundling Python binary on GNU/LinuxNamecoin (specifically Electrum-NMC) currently requires Python 3.6+, which is not yet universally available. To avoid incompatibility issues on older GNU/Linux distros, it may be worth considering bundling a Python 3.6+ binary with Tor ...Namecoin (specifically Electrum-NMC) currently requires Python 3.6+, which is not yet universally available. To avoid incompatibility issues on older GNU/Linux distros, it may be worth considering bundling a Python 3.6+ binary with Tor Browser when building with Namecoin is enabled.
(This would have also avoided legacy/trac#33749.)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34301Fix shellcheck issues in our tor-browser-build scripts2023-01-05T15:03:10ZGeorg KoppenFix shellcheck issues in our tor-browser-build scriptsWe add more and more shell scripts for different tasks into our `tor-browser-build` repo, which is great. We should go over the already existing ones and fix `shellcheck` issues.
This is the parent ticket for that effort.We add more and more shell scripts for different tasks into our `tor-browser-build` repo, which is great. We should go over the already existing ones and fix `shellcheck` issues.
This is the parent ticket for that effort.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/34110Investigate `./mach android gradle-dependencies` for our use cases2022-08-03T12:18:56ZGeorg KoppenInvestigate `./mach android gradle-dependencies` for our use casesMozilla has a neat way of automating the gradle dependencies it needs during build time and making them available: https://firefox-source-docs.mozilla.org/build/buildsystem/toolchains.html#firefox-for-android-with-gradle
We should think...Mozilla has a neat way of automating the gradle dependencies it needs during build time and making them available: https://firefox-source-docs.mozilla.org/build/buildsystem/toolchains.html#firefox-for-android-with-gradle
We should think about how we could use that either just for Fenix or in general for our mobile related projects.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34051Generate list of all dependencies and additional files2023-11-07T12:36:49ZMatthew FinkelGenerate list of all dependencies and additional filesExternal Tor Browser packages (for other platforms) would find it helpful if we produce a list of all dependencies used for building Tor Browser for a platform and if those dependencies were built using custom patches. This list should i...External Tor Browser packages (for other platforms) would find it helpful if we produce a list of all dependencies used for building Tor Browser for a platform and if those dependencies were built using custom patches. This list should include any additional files we inject into the final packages (such as licenses, start script, fonts, etc.).https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34046Sign commits with gpg2023-01-05T15:06:47ZboklmSign 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/tpo/applications/tor-browser-build/-/issues/34022Rename the testbuild/torbrowser-testbuild targets2023-01-05T12:55:57ZboklmRename the testbuild/torbrowser-testbuild targetsFor release, alpha and nightly we use the same target name in `projects/release/config` and other components.
For testbuild however, we use the `testbuild` target in `projects/release/config`, which is using the `torbrowser-testbuild` t...For release, alpha and nightly we use the same target name in `projects/release/config` and other components.
For testbuild however, we use the `testbuild` target in `projects/release/config`, which is using the `torbrowser-testbuild` target (defined in rbm.conf) for building other components, which can be confusing. There is also a `testbuild` target in rbm.conf, which is used by `torbrowser-testbuild`.
I think we could fix that by renaming the `torbrowser-testbuild` target we have in `rbm.conf` to `testbuild`, and the current `testbuild` target to `testbuild-common`.
This will however require that people who use a custom `rbm.local.conf` update it.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/33936Make our fetch-gradle-dependencies script smarter regarding dependency location2022-08-03T12:22:36ZGeorg KoppenMake our fetch-gradle-dependencies script smarter regarding dependency locationWe fetch gradle dependencies with our `fetch-gradle-dependencies` script but don't really care where exactly we put them in that process. We should change that, though, because otherwise we need to do things like
`cp -r $gradle_repo/m2/*...We fetch gradle dependencies with our `fetch-gradle-dependencies` script but don't really care where exactly we put them in that process. We should change that, though, because otherwise we need to do things like
`cp -r $gradle_repo/m2/* $gradle_repo` in build scripts to adjust the paths so that gradle can find them.
That's a thing our script should do in the first place to avoid complexity in our build scripts.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/33013Add file listing the main rules for tor-browser-build rbm files2023-01-05T14:20:33ZboklmAdd file listing the main rules for tor-browser-build rbm filesWe should add a file listing the main rules to follow when making changes to tor-browser-build.
legacy/trac#33012 is one example, but there are probably others.We should add a file listing the main rules to follow when making changes to tor-browser-build.
legacy/trac#33012 is one example, but there are probably others.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32898Get rid of binary blobs in source code/toolchains we use/build for building T...2023-01-05T14:19:21ZGeorg KoppenGet rid of binary blobs in source code/toolchains we use/build for building Tor BrowserOver the years we have accumulated binary blobs in the source code/toolchains we take for building Tor Browser. This is the parent ticket to track those issues.
Note: this ticket is *not* concerned with the toolchains/packages that come...Over the years we have accumulated binary blobs in the source code/toolchains we take for building Tor Browser. This is the parent ticket to track those issues.
Note: this ticket is *not* concerned with the toolchains/packages that come with the OS we use for building.
- [ ] #19181
- [ ] #23045https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32523Consider building tor-browser-build containers with Bitcoin Core's Guix-based...2023-01-05T14:20:28ZJeremyRandConsider building tor-browser-build containers with Bitcoin Core's Guix-based systemBitcoin Core recently merged a PR from Carl Dong (from Chaincode Labs) that allows building Bitcoin Core using containers that are constructed via GNU Guix, instead of using an OS ISO or debootstrap. This provides better security agains...Bitcoin Core recently merged a PR from Carl Dong (from Chaincode Labs) that allows building Bitcoin Core using containers that are constructed via GNU Guix, instead of using an OS ISO or debootstrap. This provides better security against supply-chain attacks by reducing the amount of trusted binary code used to bootstrap the build system. Bitcoin Core intends to use Carl's system as a replacement for Gitian.
It would be interesting to investigate whether tor-browser-build could transition to constructing its containers via Bitcoin Core's new system instead of using debootstrap.
A talk that Carl gave at Breaking Bitcoin about the new system is here:
https://www.youtube.com/watch?v=I2iShmUTEl8
A transcript of Carl's talk (transcribed by Bryan Bishop) is here:
https://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/bitcoin-build-system/
Here's the PR that Carl submitted to Bitcoin Core:
https://github.com/bitcoin/bitcoin/pull/15277
And here's the documentation in Bitcoin Core's master branch:
https://github.com/bitcoin/bitcoin/tree/master/contrib/guix
GNU/Linux targets are already working and are merged; macOS and Windows are working as well but I think Carl hasn't gotten those merged to Bitcoin Core yet. I have no idea what the situation is with Android/Linux.
Bitcoin Core isn't yet using Carl's system to build their official binaries, so it might be wise for Tor to let Bitcoin Core torture-test the code a bit in production first, but it does look like a very nice system, and it would be great to see it used for Tor Browser in the future.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32477Clean up obfs4/go build on Android2023-01-05T14:16:33ZboklmClean up obfs4/go build on AndroidWith legacy/trac#28803 (commit eee5d30a9ab1d727caac262cb62f72aaab75e0a0), we added support for Android for the obfs4 build.
In some of the go dependencies, we setup `var/compiler` (for example `gobsaes`), but not in some others (for exa...With legacy/trac#28803 (commit eee5d30a9ab1d727caac262cb62f72aaab75e0a0), we added support for Android for the obfs4 build.
In some of the go dependencies, we setup `var/compiler` (for example `gobsaes`), but not in some others (for example `ed25519`).
We should:
- understand why it is needed for some projects and not others
- check if it is really needed for all the projects where we add it
- understand why it is needed for Android, but not for the other platformshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32416Add some documentation about building go libraries/programs with build_go_lib2023-01-05T14:16:24ZboklmAdd some documentation about building go libraries/programs with build_go_libAs `build_go_lib` template is getting more complex, we should add some documentation about how to use it, probably into 'README.HACKING'.As `build_go_lib` template is getting more complex, we should add some documentation about how to use it, probably into 'README.HACKING'.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32259Tor Browser fails to start on some Linux systems without libatomic being inst...2022-08-03T15:00:51ZGeorg KoppenTor Browser fails to start on some Linux systems without libatomic being installedE.g. Trisquel 8 32bit seems to be affected, ses [this](https://blog.torproject.org/comment/284606#comment-284606) thread on our blog.
Our Tor Browser 8.5.5 worked on those systems, though.E.g. Trisquel 8 32bit seems to be affected, ses [this](https://blog.torproject.org/comment/284606#comment-284606) thread on our blog.
Our Tor Browser 8.5.5 worked on those systems, though.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/31864Provide Tor Browser for Windows arm642022-12-22T10:52: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.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/31860Start using LTO for firefox project2023-01-05T14:16:07ZGeorg KoppenStart using LTO for firefox projectThere are a number of platforms where Mozilla is using LTO in their builds. We should switch to that if possible by setting the respective `MOZ_LTO` env variable.
This is the parent ticket.
We might want to test this thoroughly as ther...There are a number of platforms where Mozilla is using LTO in their builds. We should switch to that if possible by setting the respective `MOZ_LTO` env variable.
This is the parent ticket.
We might want to test this thoroughly as there are probably reproducibility issues involved (glandium mentioned the other day that Mozilla's macOS builds are not reproducible anymore which is not the case for us; the best explanation he could come up with was that LTO is causing that).https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/31846Clean up mingw-w64 project to make it clean2022-08-03T13:44:16ZcypherpunksClean up mingw-w64 project to make it clean> The pthread situation is a bit unfortunate.
It doesn't seem that Rust depends on winpthread: https://github.com/rust-lang/rust/issues/13501
Have you changed `--enable-threads=posix` to `--enable-threads=win32`?
Also you can remove old...> The pthread situation is a bit unfortunate.
It doesn't seem that Rust depends on winpthread: https://github.com/rust-lang/rust/issues/13501
Have you changed `--enable-threads=posix` to `--enable-threads=win32`?
Also you can remove old `--with-gnu-ld --with-gnu-as`.
> # LDFLAGS_FOR_TARGET does not work for some reason. Thus, we take
> # CFLAGS_FOR_TARGET.
It didn't work, because linker didn't want to eat `-specs`. Try now.
Also where are `--no-seh`, `--large-address-aware` for x86 and `--high-entropy-va`, `--image-base` for x64?
> `--enable-sdk=all --enable-secure-api`
They are no longer needed (set by default).