Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:25:56Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32479Consider publishing signatures as .sig instead of .asc2020-06-16T01:25:56ZMatthew FinkelConsider publishing signatures as .sig instead of .ascSomeone posted a blog comment with this request. It doesn't seem unreasonable.
https://blog.torproject.org/comment/285450#comment-285450Someone posted a blog comment with this request. It doesn't seem unreasonable.
https://blog.torproject.org/comment/285450#comment-285450https://gitlab.torproject.org/legacy/trac/-/issues/32477Clean up obfs4/go build on Android2020-06-16T01:25:55ZboklmClean up obfs4/go build on AndroidWith #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 `ed255...With #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/legacy/trac/-/issues/32416Add some documentation about building go libraries/programs with build_go_lib2020-06-16T01:25:55ZboklmAdd 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/legacy/trac/-/issues/32355Tor Browser for Linux/ARMv7 (x86_64 build arch)2020-06-16T01:25:51ZJeremyRandTor Browser for Linux/ARMv7 (x86_64 build arch)The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and...The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and probably other platforms too.
This ticket is specifically for building Tor Browser for ARMv7 targets with the x86_64 build arch.https://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/32182var/num_procs is not used when building firefox2020-06-16T01:25:48Zboklmvar/num_procs is not used when building firefoxSince commit `74e8c6a9803cc778b73dfa08c23ab7c75bb40718`, `var/num_procs` is not used anymore to select the number of parallel processes used to build firefox.
It seems we need to set the `MOZ_PARALLEL_BUILD` environment variable to sele...Since commit `74e8c6a9803cc778b73dfa08c23ab7c75bb40718`, `var/num_procs` is not used anymore to select the number of parallel processes used to build firefox.
It seems we need to set the `MOZ_PARALLEL_BUILD` environment variable to select the number of processes `./mach build` will use.https://gitlab.torproject.org/legacy/trac/-/issues/31996Consider using mmdebstrap instead of debootstrap2020-06-16T01:25:48ZboklmConsider using mmdebstrap instead of debootstrapWe are currently using debootstrap to generate our Debian images. We might want to switch to mmdebstrap:
https://gitlab.mister-muffin.de/josch/mmdebstrap
It seems using mmdebstrap would make the creation of chroots faster (because of us...We are currently using debootstrap to generate our Debian images. We might want to switch to mmdebstrap:
https://gitlab.mister-muffin.de/josch/mmdebstrap
It seems using mmdebstrap would make the creation of chroots faster (because of using apt directly, and because security updates do not need to be installed in a separate step). Although we only create one base chroot tarball for each Debian release, so this wouldn't make a significant difference in overall build time.
An other interesting feature is support for Linux user namespaces, allowing the creation of chroot tarball without root access, which could help for #23631.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/31925Submit Request to Update Apktool For Buster2020-06-16T01:25:45ZShane IsbellSubmit Request to Update Apktool For BusterNeed Apktool 2.4 for busterNeed Apktool 2.4 for busterhttps://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/31860Start using LTO for firefox project2020-06-16T01:25:45ZGeorg 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/legacy/trac/-/issues/31846Clean up mingw-w64 project to make it clean2020-06-16T01:25:44ZcypherpunksClean 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).https://gitlab.torproject.org/legacy/trac/-/issues/31845Bump GCC to 9.32020-06-16T01:25:44ZcypherpunksBump GCC to 9.3GCC depends on MPC which depends on MPFR which depends on GMP.
Please, update GCC with dependencies everywhere.GCC depends on MPC which depends on MPFR which depends on GMP.
Please, update GCC with dependencies everywhere.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/31828Get rid of libwinpthread when switching tor to mingw-w64-clang2020-06-16T01:25:43ZGeorg KoppenGet rid of libwinpthread when switching tor to mingw-w64-clangThere is no need to ship libwinprthread when compiling `tor` with mingw-w64-clang. See: #31584 for context.
Note this is strictly speaking a parent ticket for #29321. However, Trac thinks any child can only have one parent. So, here we ...There is no need to ship libwinprthread when compiling `tor` with mingw-w64-clang. See: #31584 for context.
Note this is strictly speaking a parent ticket for #29321. However, Trac thinks any child can only have one parent. So, here we are.https://gitlab.torproject.org/legacy/trac/-/issues/31729Warning about missing GTK wayland related packages in configure script2020-06-16T01:25:42ZGeorg KoppenWarning about missing GTK wayland related packages in configure scriptWhen running the ESR 68 build on Linux one can see the following warnings
```
0:10.19 WARNING: Package gtk+-wayland-3.0 was not found in the pkg-config search path.
0:10.19 WARNING: Perhaps you should add the directory containing `gtk+...When running the ESR 68 build on Linux one can see the following warnings
```
0:10.19 WARNING: Package gtk+-wayland-3.0 was not found in the pkg-config search path.
0:10.19 WARNING: Perhaps you should add the directory containing `gtk+-wayland-3.0.pc'
0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
0:10.19 WARNING: No package 'gtk+-wayland-3.0' found
0:10.19 WARNING: Package xkbcommon was not found in the pkg-config search path.
0:10.19 WARNING: Perhaps you should add the directory containing `xkbcommon.pc'
0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
0:10.19 WARNING: No package 'xkbcommon' found
```https://gitlab.torproject.org/legacy/trac/-/issues/31716Harden obfs4proxy.exe shipped with Tor Browser2020-06-16T01:25:42ZGeorg KoppenHarden obfs4proxy.exe shipped with Tor BrowserRight now we have something like
```
Checking obfs4proxy.exe for /DYNAMICBASE... FAIL
Checking obfs4proxy.exe for /NXCOMPAT... FAIL
Checking obfs4proxy.exe for /SAFESEH... PASS
Checking /obfs4proxy.exe ImageBase (0x400000 < 4GB)... FAIL
...Right now we have something like
```
Checking obfs4proxy.exe for /DYNAMICBASE... FAIL
Checking obfs4proxy.exe for /NXCOMPAT... FAIL
Checking obfs4proxy.exe for /SAFESEH... PASS
Checking /obfs4proxy.exe ImageBase (0x400000 < 4GB)... FAIL
```
for 64bit versions and a similar output for 32bit ones. We should get rid of the `FAIL`s.https://gitlab.torproject.org/legacy/trac/-/issues/31688go build/install should pass -trimpath flag2020-06-16T01:25:41ZJeremyRandgo build/install should pass -trimpath flagGo 1.13 added a `-trimpath` flag to `go build` and `go install`, which removes all filesystem paths from the compiled executable. This fixes some reproducible build issues. To ensure optimal build reproducibility, `tor-browser-build` s...Go 1.13 added a `-trimpath` flag to `go build` and `go install`, which removes all filesystem paths from the compiled executable. This fixes some reproducible build issues. To ensure optimal build reproducibility, `tor-browser-build` should pass `-trimpath` when building Go projects.https://gitlab.torproject.org/legacy/trac/-/issues/31588Be smarter about vendoring for Rust projects2020-06-16T01:25:41ZGeorg KoppenBe smarter about vendoring for Rust projectsIn #30490 we added `cbindgen` to our projects which resulted in a large extra archive with all the vendored stuff that is specified. However, we probably don't need a lot of that stuff (like all the big Windows .a files). We should figur...In #30490 we added `cbindgen` to our projects which resulted in a large extra archive with all the vendored stuff that is specified. However, we probably don't need a lot of that stuff (like all the big Windows .a files). We should figure out a smarter way of handling that than just shipping everything.https://gitlab.torproject.org/legacy/trac/-/issues/31581KDE Desktop file error2020-06-16T01:25:40ZTracKDE Desktop file errorThe freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix...The freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix, replace the end of the Exec command with "\\" which escapes the bash continuation char.
Tor v8.5.4
**Trac**:
**Username**: Psnarfhttps://gitlab.torproject.org/legacy/trac/-/issues/31550Fix shellcheck (and related) issues in start-tor-browser2020-06-16T01:25:39ZNick MathewsonFix shellcheck (and related) issues in start-tor-browserI got a warning when I was running the script, so I ran shellcheck on it and got a bunch of warnings.I got a warning when I was running the script, so I ran shellcheck on it and got a bunch of warnings.Nick MathewsonNick Mathewson