Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:25:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26417Tor Browser build is not working with the runc version in debian testing2020-06-16T01:25:11ZboklmTor Browser build is not working with the runc version in debian testingahf reported that building tor browser on Debian testing fails with the following error:
```
Error: Error starting remote:
json: cannot unmarshal array into Go struct field Process.capabilities of type specs.LinuxCapabilities
Makefile:...ahf reported that building tor browser on Debian testing fails with the following error:
```
Error: Error starting remote:
json: cannot unmarshal array into Go struct field Process.capabilities of type specs.LinuxCapabilities
Makefile:66: recipe for target 'nightly-osx-x86_64' failed
```
The output of `runc --version` on Debian testing is:
```
$ /usr/sbin/runc --version
runc version spec: 1.0.1
```https://gitlab.torproject.org/legacy/trac/-/issues/26408Make MAR signature checks clearer when creating incremental MAR files2020-06-16T01:25:10ZGeorg 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/legacy/trac/-/issues/26302Build fonts we ship from source2020-06-16T01:25:10ZGeorg 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/legacy/trac/-/issues/26238Move from Debian Wheezy to Debian Buster for our Linux builds2020-06-16T01:25:10ZGeorg KoppenMove from Debian Wheezy to Debian Buster for our Linux buildsDebian Wheezy is about to get unsupported and we should move to Debian Jessie for our Linux builds. This has the additional advantage that we don't have different Debian versions anymore to build bundles for all of our supported platform...Debian Wheezy is about to get unsupported and we should move to Debian Jessie for our Linux builds. This has the additional advantage that we don't have different Debian versions anymore to build bundles for all of our supported platforms: We are then using Debian Jessie everywhere.
The only worrying situation is the CentOS one. We should think about whether we still can and want support CentOS 6 (which we need to do anyway while switching to Firefox ESR 60 which requires GTK3) and what the CentOS 7 situation is if we start building using Jessie.https://gitlab.torproject.org/legacy/trac/-/issues/26115Think about using --enable-hardening for Firefox where applicable and clean u...2020-06-16T01:25:08ZGeorg 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/legacy/trac/-/issues/26012Add Pluggable Transport binaries to windows Expert Bundle2020-06-16T01:25:08ZTracAdd Pluggable Transport binaries to windows Expert BundleThe obfs4proxy, meek-client, and fteproxy binaries are needed for setting up pluggable transports. Currently if one wants to set up pluggable transports they have to download the whole Tor Browser package to have just those binaries! Thi...The obfs4proxy, meek-client, and fteproxy binaries are needed for setting up pluggable transports. Currently if one wants to set up pluggable transports they have to download the whole Tor Browser package to have just those binaries! This seems in contradiction with the purpose of providing Expert Bundle.
**Trac**:
**Username**: ash1991https://gitlab.torproject.org/legacy/trac/-/issues/25934Disable unnecessary bits when compiling the Rust compilers2020-06-16T01:25:07ZGeorg KoppenDisable unnecessary bits when compiling the Rust compilersWe should go over the available configure options and disable all the unnecessary bits when compiling the Rust compilers, to save compilation time, complexity, and disk space.We should go over the available configure options and disable all the unnecessary bits when compiling the Rust compilers, to save compilation time, complexity, and disk space.https://gitlab.torproject.org/legacy/trac/-/issues/25863Check where the -mwindows flag is needed2020-06-16T01:25:07ZboklmCheck 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.https://gitlab.torproject.org/legacy/trac/-/issues/25835Move build dependencies from people.tpo2020-06-16T01:25:06ZboklmMove 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.https://gitlab.torproject.org/legacy/trac/-/issues/25102Add script to sign nightly build mar files, generate update-responses xml and...2020-06-16T01:25:06ZboklmAdd script to sign nightly build mar files, generate update-responses xml and publish the new versionWe need a script that will fetch the latest nightly build from the build machine, then sign the mar files and publish them.
Later we can improve it to fetch builds from multiple builders and only do the signing if they match.We need a script that will fetch the latest nightly build from the build machine, then sign the mar files and publish them.
Later we can improve it to fetch builds from multiple builders and only do the signing if they match.https://gitlab.torproject.org/legacy/trac/-/issues/24515Make the script for downloading missing MAR files smarter2020-06-16T01:25:05ZGeorg KoppenMake the script for downloading missing MAR files smarterWe should only need to download the MAR files we need for the particular context the respective script is invoked in. E.g. if it is invoked when creating the new MAR files after macOS code signing there is no need to download the non-mac...We should only need to download the MAR files we need for the particular context the respective script is invoked in. E.g. if it is invoked when creating the new MAR files after macOS code signing there is no need to download the non-macOS MAR files as well but just the needed macOS ones. However, if we want to create incrementals for all platoforms later on (for whatever reason) the script should download the missing MAR files for the other platforms we support.https://gitlab.torproject.org/legacy/trac/-/issues/24387Update tor-browser.git/.mozconfig-mac for rbm builds2020-06-16T01:25:04ZboklmUpdate tor-browser.git/.mozconfig-mac for rbm buildsThe osx64 build with rbm is using `tor-browser-build/projects/firefox/mozconfig-osx-x86_64` which is different from `tor-browser.git/.mozconfig-mac`. We should merge those changes to `tor-browser.git/.mozconfig-mac` to be able to use tha...The osx64 build with rbm is using `tor-browser-build/projects/firefox/mozconfig-osx-x86_64` which is different from `tor-browser.git/.mozconfig-mac`. We should merge those changes to `tor-browser.git/.mozconfig-mac` to be able to use that mozconfig file.https://gitlab.torproject.org/legacy/trac/-/issues/24385Add Windows 64 mozconfig file to tor-browser.git2020-06-16T01:25:03ZboklmAdd Windows 64 mozconfig file to tor-browser.gitIn `tor-browser-build.git/projects/firefox/mozconfig-windows-x86_64` we have a mozconfig file that is used for the Windows 64 builds. We should add it to `tor-browser.git`, maybe as `.mozconfig-mingw-windows64`, before removing it from `...In `tor-browser-build.git/projects/firefox/mozconfig-windows-x86_64` we have a mozconfig file that is used for the Windows 64 builds. We should add it to `tor-browser.git`, maybe as `.mozconfig-mingw-windows64`, before removing it from `tor-browser-build`.https://gitlab.torproject.org/legacy/trac/-/issues/24332Add a script to convert code signed OSX bundles from tar to dmg2020-06-16T01:25:03ZboklmAdd a script to convert code signed OSX bundles from tar to dmgDuring the signing process we code-sign the OSX bundles on our signing machine, creating tarballs containing the OSX bundles. After this step is done we need to convert those tarballs to dmg files using some build machine. We can add a s...During the signing process we code-sign the OSX bundles on our signing machine, creating tarballs containing the OSX bundles. After this step is done we need to convert those tarballs to dmg files using some build machine. We can add a script to `tor-browser-build` doing that using the same tools we use to generate the unsigned dmg files.https://gitlab.torproject.org/legacy/trac/-/issues/24331Improve the Tor Browser signing process2020-06-16T01:25:02ZboklmImprove the Tor Browser signing processThis is the parent ticket for adding more scripts to automate some parts of the signing process.This is the parent ticket for adding more scripts to automate some parts of the signing process.https://gitlab.torproject.org/legacy/trac/-/issues/23657Decide directories used for signed/unsigned builds in tor-browser-builds2020-06-16T01:25:00ZboklmDecide directories used for signed/unsigned builds in tor-browser-buildsWith gitian builds, all builds (signed and unsigned) were stored in the gitian directory directly.
I remember having issues when generating incremental mars which were done with unsigned osx mars instead of the signed ones. To avoid tha...With gitian builds, all builds (signed and unsigned) were stored in the gitian directory directly.
I remember having issues when generating incremental mars which were done with unsigned osx mars instead of the signed ones. To avoid that issue I have started with separating signed and unsigned builds in tor-browser-build. However it seems the new process is confusing and error-prone during the signing process, so we should think more about what directories we want to use in the different steps (or if we want to go back to using only one).
I think having different directories could also be useful if we want to add some scripts helping with the intermediate signing steps.
What we currently have is:
- the build target creates builds in the directory `unsigned`
- the incrementals target generates incremental mars in the `unsigned` directory. However it is using/downloading the mar files from the old version in the `unsigned` directory too, while it should be done from a signed build (for the osx ones). Maybe we should fix the incrementals step to use the old version from the `signed` directory instead.
- the dmg2mar target is using the `signed` directory. However at this point, only the dmg files are signed, so it is confusing to put all the files in the `signed` directory. Maybe an intermediate directory should be used instead?
- the update_responses target is using the `signed` directory. I think this one is correct as update responses should only be done from a fully signed build.https://gitlab.torproject.org/legacy/trac/-/issues/23656Use .mozconfig files in tor-browser repo for rbm builds2020-06-16T01:24:59ZGeorg KoppenUse .mozconfig files in tor-browser repo for rbm buildsRight now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in th...Right now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in the tor-browser repository for local builds outside of `rbm` (and only change them there when writing tor-browser patches) but use them nevertheless for `rbm`-based builds (probably with some modifications if needed).https://gitlab.torproject.org/legacy/trac/-/issues/23631Improve sudo need2020-06-16T01:24:59ZTom Rittertom@ritter.vgImprove sudo needRight now the Tor Browser build takes a long time, and sudo is needed periodically throughout it. This means you have to either run it as root, babysit it, or set your user account up with passwordless sudo. All of those kinda stink.
It...Right now the Tor Browser build takes a long time, and sudo is needed periodically throughout it. This means you have to either run it as root, babysit it, or set your user account up with passwordless sudo. All of those kinda stink.
It's be cool if we could improve that a bit. Ideas:
- Write a setuid program that execs the necessary commands but provides input and directory filtering (directory path either compiled in or read from a root-owned file I guess)
- Same idea but instead of setuid, it's set up to be run with passwordless sudo
- Somehow request sudo access in the beginning and retain it through the whole script (without running everything as root)https://gitlab.torproject.org/legacy/trac/-/issues/23401Add option to download everything needed for the build2020-06-16T01:24:58ZboklmAdd option to download everything needed for the buildWe are currently downloading files in the order in which we use them.
Some files are downloaded early (files for which we need their checksum to compute some output files), while other files are downloaded just before their component is...We are currently downloading files in the order in which we use them.
Some files are downloaded early (files for which we need their checksum to compute some output files), while other files are downloaded just before their component is built (signature files, or files for which we already know the checksum).
We should add an option to download everything without starting the build, which should then allow someone to do the build offline.https://gitlab.torproject.org/legacy/trac/-/issues/23045Replace *.tlb with our own during build time2020-06-16T01:24:57ZGeorg KoppenReplace *.tlb with our own during build timemingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get ri...mingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get rid of the ones in the repo and build them ourselves.