Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-21T18:06:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34350Stop logging all successful databse queries in GetTor2020-06-21T18:06:14ZCecylia BocovichStop logging all successful databse queries in GetTorThis is another log message that isn't helpful and fills up our logs. Here's a patch: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/gettor/-/merge_requests/12This is another log message that isn't helpful and fills up our logs. Here's a patch: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/gettor/-/merge_requests/12Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/34303Find out why onion service measurements have gotten slower2020-06-13T15:53:42ZKarsten LoesingFind out why onion service measurements have gotten slowerToday I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torp...Today I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torproject.org/torperf.html?start=2020-02-25&end=2020-05-25&server=onion&filesize=50kb) and found that the onion service measurements made by op-nl2, op-us2, and op-hk2 have gotten much slower as compared to their op-nl, op-us, and op-hk predecessors.
I'm 95% certain that this is not a bug in the graphs.
My current best guess is that something in `tor` has changed. I'd like to set up a small number of experimental OnionPerf instances all in the same place but with different `tor` versions. Any suggestions on locations (Amsterdam, Florida, Hong Kong) or `tor` versions?
This is also relevant to Sponsor 59 in order to make sure that our current measurements are going to be a baseline for future experiments. Classifying as potential defect.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34209about:tor and about:tbupdate fail to load in debug build of Tor Browser2020-06-16T01:13:03ZMark Smithabout:tor and about:tbupdate fail to load in debug build of Tor BrowserWhen using a debug build based on acat's 33533+5 branch, trying to open about:tor or about:tbupdate leads to an assertion failure and a tab crash:
Assertion failure: foundObjectSrc (about: page must contain a CSP denying object-src), at...When using a debug build based on acat's 33533+5 branch, trying to open about:tor or about:tbupdate leads to an assertion failure and a tab crash:
Assertion failure: foundObjectSrc (about: page must contain a CSP denying object-src), at /.../dom/security/nsContentSecurityUtils.cpp:818
We need to add `object-src 'none'` to the CSP for those pages.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/34198Include full broker messaging spec in /doc2020-06-13T18:22:07ZCecylia BocovichInclude full broker messaging spec in /docThis adds information about the broker API, with the messaging protocol and the endpoints used by clients and proxies.
This is a prerequisite for our work to implement a Snowflake proxy on Android.This adds information about the broker API, with the messaging protocol and the endpoints used by clients and proxies.
This is a prerequisite for our work to implement a Snowflake proxy on Android.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/34187Update zlib build script to pick up new android toolchain2020-06-16T01:26:25ZGeorg KoppenUpdate zlib build script to pick up new android toolchainIt seems in order to pick up the new android toolchain we need to update our `zlib` project as well.It seems in order to pick up the new android toolchain we need to update our `zlib` project as well.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34125Fix torbutton proxy api due to change in Firefox 77.2020-06-16T01:28:35ZAlex CatarineuFix torbutton proxy api due to change in Firefox 77.We should fix torbutton code due to the breaking API change in `nsIProtocolProxyFilter` from https://bugzilla.mozilla.org/show_bug.cgi?id=1584797.We should fix torbutton code due to the breaking API change in `nsIProtocolProxyFilter` from https://bugzilla.mozilla.org/show_bug.cgi?id=1584797.https://gitlab.torproject.org/legacy/trac/-/issues/33973Create fat .aar for geckoview2020-06-16T01:26:18ZGeorg KoppenCreate fat .aar for geckoviewDownstream consumers like `android-components` and `fenix` use fat .aar files. We need to create them out of ouf per-arch ones. https://bugzilla.mozilla.org/show_bug.cgi?id=1508976 is the bug where this got implemented on Mozilla's side.Downstream consumers like `android-components` and `fenix` use fat .aar files. We need to create them out of ouf per-arch ones. https://bugzilla.mozilla.org/show_bug.cgi?id=1508976 is the bug where this got implemented on Mozilla's side.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33892Add brandProductName to torbutton brand localization files2020-06-16T01:28:34ZAlex CatarineuAdd brandProductName to torbutton brand localization files`brandProductName` was already present in ESR68, but we did not update torbutton `brand.dtd` or `brand.properties` files. For 68, this does not break the browser, since `brandProductName` is not used as an xml entity (DTD), and the `.pro...`brandProductName` was already present in ESR68, but we did not update torbutton `brand.dtd` or `brand.properties` files. For 68, this does not break the browser, since `brandProductName` is not used as an xml entity (DTD), and the `.properties` usage is in a path we probably do not [hit](https://searchfox.org/mozilla-esr68/rev/c6e395f8a8512bec0dea4d3526831a3dbbae90e4/toolkit/profile/content/profileSelection.js#86).
Currently, this is string is used in several additional places, and starting Firefox 70 it's used as a [DTD entity](https://searchfox.org/mozilla-central/rev/b7f3977978922d44c7d92ae01c0d4cc2baca7bc2/browser/locales/en-US/chrome/browser/browser.dtd#68), which prevents the browser from starting if it's not defined.https://gitlab.torproject.org/legacy/trac/-/issues/33890Rename .xul to .xhtml2020-06-16T01:12:33ZAlex CatarineuRename .xul to .xhtmlFirefox did a mass rename of all .xul files to .xhtml in https://bugzilla.mozilla.org/show_bug.cgi?id=1579952. We need to do the same in torbutton and tor-launcher, as well as in several Tor Browser patches that involve UI.Firefox did a mass rename of all .xul files to .xhtml in https://bugzilla.mozilla.org/show_bug.cgi?id=1579952. We need to do the same in torbutton and tor-launcher, as well as in several Tor Browser patches that involve UI.https://gitlab.torproject.org/legacy/trac/-/issues/33862Fix usages of createTransport API2020-06-16T01:12:27ZAlex CatarineuFix usages of createTransport APIThere was a nsISocketTransportService breaking change in https://bugzilla.mozilla.org/show_bug.cgi?id=1558726. We have to fix those in torbutton and tor-launcher.There was a nsISocketTransportService breaking change in https://bugzilla.mozilla.org/show_bug.cgi?id=1558726. We have to fix those in torbutton and tor-launcher.https://gitlab.torproject.org/legacy/trac/-/issues/33835Gmail's quoted response confuses BridgeDB's email autoresponder2020-06-13T18:30:01ZPhilipp Winterphw@torproject.orgGmail's quoted response confuses BridgeDB's email autoresponderWhen replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are ...When replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are your bridges:
>
> [redacted]
>
> Add these bridges to your Tor Browser by opening your browser
> preferences, clicking on "Tor", and then adding them to the "Provide a
> bridge" field.
>
> If these bridges are not what you need, reply to this email with one of
> the following commands in the message body:
>
> get bridges (Request unobfuscated Tor bridges.)
> get ipv6 (Request IPv6 bridges.)
> get transport TYPE (Request obfuscated bridges. Replace TYPE with
> 'obfs4'.)
> get key (Get a copy of BridgeDB's public GnuPG key.)
>
>
>
--000000000000dde1a205a2a60f3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">get transport obfs4<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 6, 2020 at 2:12 PM <=
<a href=3D"mailto:bridges@torproject.org">bridges@torproject.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
[This is an automated email.=C2=A0 Please do not reply.]<br>
<br>
Here are your bridges:<br>
<br>
=C2=A0 [redacted]<br>
<br>
Add these bridges to your Tor Browser by opening your browser<br>
preferences, clicking on "Tor", and then adding them to the "=
;Provide a<br>
bridge" field.<br>
<br>
If these bridges are not what you need, reply to this email with one of<br>
the following commands in the message body:<br>
<br>
=C2=A0 get bridges=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Request unobfu=
scated Tor bridges.)<br>
=C2=A0 get ipv6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Requ=
est IPv6 bridges.)<br>
=C2=A0 get transport TYPE=C2=A0 =C2=A0 =C2=A0(Request obfuscated bridges. R=
eplace TYPE with 'obfs4'.)<br>
=C2=A0 get key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Get =
a copy of BridgeDB's public GnuPG key.)<br>
<br>
<br>
</blockquote></div>
--000000000000dde1a205a2a60f3e--
```
BridgeDB correctly ignores the commands that start with `>` but it doesn't ignore the commands that are encoded in quoted-printable. BridgeDB's email parser ends up [interpreting each line as command](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/distributors/email/request.py?h=develop&id=bca64964a255cf959489c7049c66e5eb70b5291c#n87), ending in "get key", which raises an exception, resulting in BridgeDB sending no response at all.
We should make sure that BridgeDB doesn't get confused by Gmail's quoted-printable response.Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/legacy/trac/-/issues/33801Upgrade Go Project to use new Android Toolchain2020-06-16T01:26:11ZShane IsbellUpgrade Go Project to use new Android ToolchainGo needs to use new NDK pathGo needs to use new NDK pathhttps://gitlab.torproject.org/legacy/trac/-/issues/33623sendme: Change default emit cell version from 0 to 12020-06-13T15:52:14ZDavid Gouletdgoulet@torproject.orgsendme: Change default emit cell version from 0 to 1In #32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.In #32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33564Upgrade ZSTD to use Android NDK 202020-06-16T01:26:09ZShane IsbellUpgrade ZSTD to use Android NDK 20This is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locationsThis is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locationshttps://gitlab.torproject.org/legacy/trac/-/issues/33563Upgrade Tor To Use Android NDK 202020-06-16T01:26:08ZShane IsbellUpgrade Tor To Use Android NDK 20This is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locationsThis is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locationsGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33561Upgrade openssl to use Android NDK 202020-06-16T01:26:07ZShane IsbellUpgrade openssl to use Android NDK 20This is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locations.This is based of the current work done in branch for android support. We need to upgrade to build with NDK 21.
Make standalone toolchain is not longer supported in NDK 21 so need to configure to use new locations.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33559Update tor-android-service To Use Updated Android Toolchain2020-06-16T01:26:06ZShane IsbellUpdate tor-android-service To Use Updated Android ToolchainWe need to upgrade android toolchain to support fenix. This requires update to tor-android-service.We need to upgrade android toolchain to support fenix. This requires update to tor-android-service.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33558Update TOPL To Use Updated Android Toolchain2020-06-16T01:26:05ZShane IsbellUpdate TOPL To Use Updated Android ToolchainWe need to upgrade android toolchain to support fenix. This requires update to TOPL build as well.We need to upgrade android toolchain to support fenix. This requires update to TOPL build as well.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33557Update Android Toolchain for Fenix2020-06-16T01:26:05ZShane IsbellUpdate Android Toolchain for FenixFenix uses an updated Android SDK and NDK.Fenix uses an updated Android SDK and NDK.Georg KoppenGeorg Koppen