Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:10:27Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32805Make creation of downloads.json optional2020-06-16T01:10:27ZboklmMake creation of downloads.json optionalIn `tools/update-responses/update_responses` we generate a `downloads.json` file containing the list of bundles available for download. However we don't need to create that file for nightly builds, and only have the .mar files available ...In `tools/update-responses/update_responses` we generate a `downloads.json` file containing the list of bundles available for download. However we don't need to create that file for nightly builds, and only have the .mar files available when running this script for the nightly updates. So we should add an option to make creation of `downloads.json` optional.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/32751Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.increme...2020-06-16T01:10:20ZboklmSetting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file tooWhen setting `var/sign_build` to `1`, the file `sha256sums-unsigned-build.txt` is getting signed automatically at the end of a build. The `sha256sums-unsigned-build.incrementals.txt` file however currently does not get signed.When setting `var/sign_build` to `1`, the file `sha256sums-unsigned-build.txt` is getting signed automatically at the end of a build. The `sha256sums-unsigned-build.incrementals.txt` file however currently does not get signed.https://gitlab.torproject.org/legacy/trac/-/issues/32750Sign nightly sha256sums files with gpg2020-06-16T01:10:19ZboklmSign nightly sha256sums files with gpgWe should sign the nightly build sha256sums with gpg.
This can be done by creating a key on the nightly build machine, and setting `var/sign_build` to `1` in `rbm.local.conf`.We should sign the nightly build sha256sums with gpg.
This can be done by creating a key on the nightly build machine, and setting `var/sign_build` to `1` in `rbm.local.conf`.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/32741CMake repository moved2020-06-16T01:10:18ZMatthew FinkelCMake repository movedI tried building a nightly, and I'm getting:
```
fatal: repository 'https://cmake.org/cmake.git/' not found
```
It looks like the git repo is not available at that url anymore. It is now on a self-hosted gitlab instance: https://gitlab....I tried building a nightly, and I'm getting:
```
fatal: repository 'https://cmake.org/cmake.git/' not found
```
It looks like the git repo is not available at that url anymore. It is now on a self-hosted gitlab instance: https://gitlab.kitware.com/cmake/cmake.git
Maybe this is a temporary glitch, and the first url will work again tomorrow. I tried searching for an announcement about that url being deprecated, but I haven't found one yet.https://gitlab.torproject.org/legacy/trac/-/issues/32739Bump clang to 8.0.12020-06-16T01:10:17ZGeorg KoppenBump clang to 8.0.1While rebuilding a lot of our toolchains for #32053 anyway let's fix clang bugs that already got fixed in the 8.0 cycle and bump our clang to 8.0.1While rebuilding a lot of our toolchains for #32053 anyway let's fix clang bugs that already got fixed in the 8.0 cycle and bump our clang to 8.0.1Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/32738If the linux64 mar-tools does not exist, we should use the other mar-tools av...2020-06-16T01:10:17ZboklmIf the linux64 mar-tools does not exist, we should use the other mar-tools availableIn `tools/update-responses/update_responses` we currently extract the linux64 version of the mar tools, and fail if it is not available. However in the case of nightly builds, we build each architecture separately, and don't have the lin...In `tools/update-responses/update_responses` we currently extract the linux64 version of the mar tools, and fail if it is not available. However in the case of nightly builds, we build each architecture separately, and don't have the linux64 mar tools available when generating incremental mars for the other archs.
As the `mar` program is always built for linux64, I think we could use any of the mar-tools to available.
This will however require that the nightly build machine is running an OS with a glibc more recent than the one used in the builds (so doing #32736 before we update the Windows and macOS builds to buster).boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/32676Consider publishing a tarball with all Tor Browser langpacks2020-06-16T01:10:11ZintrigeriConsider publishing a tarball with all Tor Browser langpacksAt the moment, during a build of Tails, we download all Tor Browser Linux x86_64 tarballs, in order to grab every langpack XPI, which we then all ship in our images. This causes trouble for 2 categories of Tails contributors:
* The Tail...At the moment, during a build of Tails, we download all Tor Browser Linux x86_64 tarballs, in order to grab every langpack XPI, which we then all ship in our images. This causes trouble for 2 categories of Tails contributors:
* The Tails release manager has to semi-automatically download all these tarballs and then upload them to the Tails infrastructure (that's because at this time, the tarballs are available only on people.torproject.org, and later they will disappear from there; we need a stable URL that we can encode in our Git tree, for convenience and reproducibility purposes); this consumes time, bandwidth, and storage.
* After a new Tor Browser has been imported into Tails, next time any Tails developer wants to build Tails, as part of the build, downloads each of these tarballs. This consumes time, bandwidth, and patience.
One possible solution for these problems would be to publish, on Tor Browser team's side, an additional tarball, that contains all langpack XPIs, and nothing else. According to boklm, this tarball would about 16 MB large.
Then, the Tails release manager would only have to import the en-US tarball and this all-langpacks tarball. Similarly, Tails developers would also have to download only these 2 files.
This is _not_ a duplicate of #17400 nor #12967, which are about providing end-users a multi-lingual Tor Browser.https://gitlab.torproject.org/legacy/trac/-/issues/32674Change link on 'Get involved' in about:tor to new community portal2020-06-16T01:28:33ZemmapeelChange link on 'Get involved' in about:tor to new community portalThe link to 'Get involved should not point to the old volunteer page, now that we have the new community page.
The link should be localized, as the manual and others on that page, although for the moment there are no translations enable...The link to 'Get involved should not point to the old volunteer page, now that we have the new community page.
The link should be localized, as the manual and others on that page, although for the moment there are no translations enabled, but we can do some .htacess foo meanwhile on the community portal as we plan to translate it and it has a lot of content.
![get_involved.png](uploads/get_involved.png)Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/32659Remove IPv6 address of dgoulet's default bridge2020-06-16T01:10:10ZPhilipp Winterphw@torproject.orgRemove IPv6 address of dgoulet's default bridgeThe default bridge `CDF2E852BF539B82BD10E27E9115A31734E378C2` has both an IPv4 and an IPv6 address but isn't reachable over IPv6. David says that he migrated to a new host a while ago, and this new host doesn't have IPv6. Let's remove t...The default bridge `CDF2E852BF539B82BD10E27E9115A31734E378C2` has both an IPv4 and an IPv6 address but isn't reachable over IPv6. David says that he migrated to a new host a while ago, and this new host doesn't have IPv6. Let's remove the IPv6 address of this bridge. I'll push patches in a minute.https://gitlab.torproject.org/legacy/trac/-/issues/32636Clean up locales shipped with Tor Launcher2020-06-13T17:44:25ZGeorg KoppenClean up locales shipped with Tor LauncherNow that #29941 is basically fixed on the server-side we are getting all the new goodness with the next translations fetch. We should clean-up the locales we ship while doing so (removing the ones we don't support anymore etc.). Addition...Now that #29941 is basically fixed on the server-side we are getting all the new goodness with the next translations fetch. We should clean-up the locales we ship while doing so (removing the ones we don't support anymore etc.). Additionally, we should adapt all the scripts around translation update imports if that's needed. And, after checking everything is still working we need to backport the changes to a stable branch (as the locale updates that landed in 9.5a3 will ride the train).Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/32547Set up default bridge at the University of Minnesota2020-06-16T01:09:56ZPhilipp Winterphw@torproject.orgSet up default bridge at the University of MinnesotaA research group at the University of Minnesota generously agreed to running a default bridge for us. Let's use this ticket to coordinate the process of adding it to Tor Browser.A research group at the University of Minnesota generously agreed to running a default bridge for us. Let's use this ticket to coordinate the process of adding it to Tor Browser.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32531Back out the backport for bug 15343392020-06-16T01:09:53ZGeorg KoppenBack out the backport for bug 1534339Mozilla [backed their patch out](https://hg.mozilla.org/mozilla-central/rev/9f6892c03bd8). We should do the same for our alpha builds.Mozilla [backed their patch out](https://hg.mozilla.org/mozilla-central/rev/9f6892c03bd8). We should do the same for our alpha builds.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/32520Output of go project contains nonreproducible datetime values2020-06-16T01:09:50ZJeremyRandOutput of go project contains nonreproducible datetime valuesSteps to reproduce:
1. Run `./rbm/rbm build go --target release --target torbrowser-linux-x86_64` twice.
2. Compare the hashes of the results.
Expected behavior:
The hashes should be reproducible.
Observed behavior:
The hashes are n...Steps to reproduce:
1. Run `./rbm/rbm build go --target release --target torbrowser-linux-x86_64` twice.
2. Compare the hashes of the results.
Expected behavior:
The hashes should be reproducible.
Observed behavior:
The hashes are not reproducible.
Other info:
I'm attaching a diffoscope. Most of the nonreproducibility seems to be due to datetime values. I suspect, but have not verified, that these datetime values are being inserted by the (currently unmaintained) Go 1.4.x compiler, and that therefore we can't expect an upstream fix. libfaketime seems like the most straightforward way to fix the issue. Would a patch be accepted that uses libfaketime to make the datetime values in the `go` project's output reproducible?https://gitlab.torproject.org/legacy/trac/-/issues/32116Fix tor-browser's .mozconfig so that ./mach configure succeeds on Linux by de...2020-06-16T01:08:29ZrichardFix tor-browser's .mozconfig so that ./mach configure succeeds on Linux by defaultCurrently --enable-tor-browser-update needs to be removed and --with-tor-browser-version=FOO need to be added to the .mozconfig for the tor-browser project to build. The tor-browser-build build system uses its own per-platform mozconfig ...Currently --enable-tor-browser-update needs to be removed and --with-tor-browser-version=FOO need to be added to the .mozconfig for the tor-browser project to build. The tor-browser-build build system uses its own per-platform mozconfig when building tor-browser releases, so updating the one in tor-browser will not affect official builds.richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32053Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimi...2020-06-16T01:10:17ZGeorg KoppenTor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimization issue)For some reasons boklm and I got different macOS bundles when building our rc for 9.0a8. Linux bundles are affected, too (seee #32052) and other platforms as well.For some reasons boklm and I got different macOS bundles when building our rc for 9.0a8. Linux bundles are affected, too (seee #32052) and other platforms as well.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/31855Remove End of Year Fundraising Campaign from about:tor2020-06-16T01:07:45ZPili GuerraRemove End of Year Fundraising Campaign from about:torAt the start of 2020, we should remove the EOY Fundraising elements from Tor BrowserAt the start of 2020, we should remove the EOY Fundraising elements from Tor Browserrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/31134Reenable Graphite for font rendering2020-06-16T01:05:39ZGeorg KoppenReenable Graphite for font renderingWe disabled using Graphite for font rendering (after trying to reenable it) back in #21726 for security reasons. Things have settled down it seems. Thus, we should reenable it and put it back on the security slider this time.We disabled using Graphite for font rendering (after trying to reenable it) back in #21726 for security reasons. Things have settled down it seems. Thus, we should reenable it and put it back on the security slider this time.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/30558Namecoin support for onion sites in Tor Browser2020-06-16T01:04:05ZArthur EdelsteinNamecoin support for onion sites in Tor Browser**The problem**
Onion domains are generally almost impossible for humans to remember. Specifically, they are very long and consist of a series of random characters.
v2 domains look like this:
* https://www.propub3r6espa33w.onion/
and v...**The problem**
Onion domains are generally almost impossible for humans to remember. Specifically, they are very long and consist of a series of random characters.
v2 domains look like this:
* https://www.propub3r6espa33w.onion/
and v3 domains look like this:
* http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion
So, while onion domains are secure and decentralized, they are not human-meaningful, and thus fail to satisfy all three desired properties described in [Zooko's triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle).
**Proposed solution**
Namecoin offers a solution for Zooko's triangle. Domains are registered in a decentralized manner, can be remembered by humans, and are secure. A Namecoin (.bit) domain looks like this:
* http://federalistpapers.bit
The .bit domains can be pointed to a unique .onion domain. So the user needs only to enter http://federalistpapers.bit and they will be taken to the appropriate onion site (in this case, http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion)
The task consists of writing patches for Tor Browser that integrates a Namecoin lookup client, such that when a user enters a .bit domain name the browser is connected to the underlying .onion site. In the address bar, the entered address including a .bit domain will continue to be shown, and the .onion domain will be indicated on the circuit display.
Initially, the patches can be integrated into Tor Browser Nightly. If testing is successful, I hope it could progress to Tor Browser alpha and eventually stable.
** Comparison to other approaches **
There are several promising approaches to allowing human-meaningful aliases to onion sites. However, they don't fully solve Zooko's triangle:
* HTTPS Everywhere: Aliases are under central control by the addon maintainer.
* Bookmarks/Petnames: Aliases are not global.
* Alt-Svc/Onion-Location: Aliases require first connecting through a centralized ICANN domain.
I think Namecoin is especially promising because it can be globally registered and maintained securely by the onion site operator, without any centralized permission. Thus the properties of security and decentralization offered by .onion domains are shared by .bit domains.
There are some challenges:
* Historically, Namecoin lookup has been slow and required cumbersome downloads. Jeremy has made major progress in reducing the footprint.
* Registering a Namecoin domain requires downloading specialized software and is not anonymous without special precautions. Future work (out of scope here) could include building documentation and/or software tools to allow onion operators to easily and anonymously register a .bit domain and point it to a .onion domain.JeremyRandJeremyRandhttps://gitlab.torproject.org/legacy/trac/-/issues/26861Bump available ulimit in runc container in tor-browser-build2020-06-16T00:48:35ZGeorg KoppenBump available ulimit in runc container in tor-browser-buildtjr hit a build failure with `ulimit` set to 1024 (see: comment:7:ticket:26476). I've never seen this before, so I am not sure what the underlying problem is but we should fix it. It turns out that's easily doable by raising the limit in...tjr hit a build failure with `ulimit` set to 1024 (see: comment:7:ticket:26476). I've never seen this before, so I am not sure what the underlying problem is but we should fix it. It turns out that's easily doable by raising the limit in `projects/common/runc-config.json`. Not sure, what number we should pick, though, but tjr went with 65535.https://gitlab.torproject.org/legacy/trac/-/issues/25101Generate incremental mar files for nightly builds2020-06-16T00:43:45ZboklmGenerate incremental mar files for nightly buildsWe have some nightly builds being done at http://f4amtbsowhix7rrf.onion/. However, there is no incremental mar files.
To avoid users downloading a complete mar file each day, we should generate incremental mar files from the previous da...We have some nightly builds being done at http://f4amtbsowhix7rrf.onion/. However, there is no incremental mar files.
To avoid users downloading a complete mar file each day, we should generate incremental mar files from the previous days. I think we can start with incrementals for the previous 2 days.boklmboklm