Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:52Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32673'buf_read_from_tls()' can return the wrong error code2020-06-13T15:48:52Zopara'buf_read_from_tls()' can return the wrong error codeThe [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it correspo...The [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it corresponds to a `TOR_TLS_` status) or a positive number (in which case it corresponds to the number of bytes read). This return value is [used in](https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/connection.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n3749) `connection_buf_read_from_socket()` in a large `switch(result)` statement.
At the beginning of `buf_read_from_tls(...)`, it returns `-1` on the lines:
```
IF_BUG_ONCE(buf->datalen >= INT_MAX)
return -1;
IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most)
return -1;
```
This value of `-1` is the [same as](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls.h?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n48) `TOR_TLS_WANTWRITE`. This causes the switch statement in `connection_buf_read_from_socket()` to interpret the return value as `TOR_TLS_WANTWRITE`, which is not correct for the `buf->datalen >= INT_MAX` bug. I suggest returning `TOR_TLS_ERROR_MISC` instead of `-1`. Note that this would close the connection.
I don't think you'll see incorrect behavior due to this, but it might be a good idea to fix.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://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/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/33290Add diagnostics for confusing corruption issue #32564 in ewma2020-06-13T15:51:22ZNick MathewsonAdd diagnostics for confusing corruption issue #32564 in ewmaI haven't been able to figure out why we might be hitting #32564, so the logical solution is to try to make the diagnosis better if it happens.I haven't been able to figure out why we might be hitting #32564, so the logical solution is to try to make the diagnosis better if it happens.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32961Backport the diagnostic logs for is_possible_guard crash2020-06-13T15:49:59ZteorBackport the diagnostic logs for is_possible_guard crashLet's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Let's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28992Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion ...2020-06-13T15:36:17ZtraumschuleBug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.(likely follow-up of #28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_c...(likely follow-up of #28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:05.287 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.522 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.523 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.569 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.570 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.613 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.615 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
...
Jan 04 08:48:21.767 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.772 [warn] Bug: Non-fatal assertion !(ip == NULL) failed in send_introduce1 at ../src/feature/hs/hs_client.c:571. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x65) [0x681d35] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x67d55d] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x23c) [0x58070c] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x797) [0x514317] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x171) [0x517b61] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x82) [0x580d92] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x235) [0x5cb345] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0xa0c04) [0x532c04] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x38a) [0x53515a] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(command_process_cell+0x181) [0x515111] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x34a) [0x4f9cea] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x8beed) [0x51deed] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x4a931) [0x4dc931] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_handle_read+0x9a4) [0x4e6784] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x5ab79) [0x4ecb79] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/lib/i386-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7d1) [0xb7619681] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x61dfe0] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(do_main_loop+0xc5) [0x4edfe5] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0x1ce) [0x4d996e] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_run_main+0x11c5) [0x4dad25] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_main+0x3f) [0x4d7ebf] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(main+0x35) [0x4d7a15] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb6f65b41] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x45a71) [0x4d7a71] (on Tor 0.4.0.0-alpha-dev )
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33131Bug: buf->datalen >= 0x7fffffff2020-06-13T15:50:38ZcypherpunksBug: buf->datalen >= 0x7fffffffWith
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:...With
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:32:37.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(ASSERT_PREDICT
_UNLIKELY_(buf->datalen >= 0x7fffffff - at_most)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Feb 02 06:32:37.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(ASSERT_PREDICT_UNLIKELY_(buf->datalen >= 0x7fffffff - at_mo
st)) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not available) (on Tor 0.4.2.5 )
```
Looks like some INT_MAX buffer count trouble to me at least.
```
# BandwidthRate BandwidthRate __N__ bytes|KBytes|MBytes|GBytes|TBytes|KBits|MBits|GBits|TBits
# A token bucket limits the average incoming bandwidth usage on this node
# to the specified number of bytes per second, and the average outgoing
# bandwidth usage to that same value. If you want to run a relay in the
# public network, this needs to be _at the very least_ 75 KBytes for a
# relay (that is, 600 kbits) or 50 KBytes for a bridge (400 kbits) -- but of
# course, more is better; we recommend at least 250 KBytes (2 mbits) if
# possible. (Default: 1 GByte) +
# +
# Note that this option, and other bandwidth-limiting options, apply to TCP
# data only: They do not count TCP headers or DNS traffic. +
# +
# With this option, and in other options that take arguments in bytes,
# KBytes, and so on, other formats are also supported. Notably, "KBytes" can
# also be written as "kilobytes" or "kb"; "MBytes" can be written as
# "megabytes" or "MB"; "kbits" can be written as "kilobits"; and so forth.
# Tor also accepts "byte" and "bit" in the singular.
# The prefixes "tera" and "T" are also recognized.
# If no units are given, we default to bytes.
# To avoid confusion, we recommend writing "bytes" or "bits" explicitly,
# since it's easy to forget that "B" means bytes, not bits.
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32315Can't perform reverse DNS lookup for a (binary) IPv6 address2020-06-13T15:47:35ZTracCan't perform reverse DNS lookup for a (binary) IPv6 addressTor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument ...Tor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument which can either be a binary IPv4 or IPv6 address, or an ASCII string.
Somewhat contrary to ticket #32314, this command works for IPv6 addresses only if the address is specified as an ASCII string (address type 3) with no brackets. If the address is specified in binary (address type 4), or as a string enclosed in brackets, Tor will reject it.
**Trac**:
**Username**: liberatTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33087closing stdio fds on exit can interfere with LeakSanitizer, etc2020-06-13T15:50:28ZTaylor Yuclosing stdio fds on exit can interfere with LeakSanitizer, etcAt tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config sett...At tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config setting like `Log notice stderr`. (valgrind doesn't seem to have this problem, maybe because it runs a separate process?)
Is it correct for us to close a default fd like stderr or stdout if we're not running as a daemon? Other tools that do runtime interception might also be affected. If we think we have a good reason to explicitly close these fds, we probably should document how tor's closing of these fds can interfere with debugging tools.
nickm thinks this behavior might be new in 0.4.2 with the signal safety work. I haven't had time to investigate further.Tor: 0.4.2.x-finalteorteorhttps://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/33032Decode key files with Unix or Windows newlines2020-06-13T15:50:11ZTracDecode key files with Unix or Windows newlinesUpdate:
> In my case culprit was the line endings in PEM, lines were terminated Windows-style - {CR}{LF}. Changed them to {LF} and keys were read just fine.
After the upgrade to v 0.3.5.8 my onion wasn't available anymore.
This is t...Update:
> In my case culprit was the line endings in PEM, lines were terminated Windows-style - {CR}{LF}. Changed them to {LF} and keys were read just fine.
After the upgrade to v 0.3.5.8 my onion wasn't available anymore.
This is the info I get when attempting to start tor:
Jan 23 00:29:34.000 [warn] Error decoding PEM wrapper while reading private key
Jan 23 00:29:34.000 [warn] Unable to decode private key from file "/var/lib/tor/hidden_service//private_key"
Jan 23 00:29:34.000 [err] Error loading private key.
Jan 23 00:29:34.000 [warn] Error loading rendezvous service keys
Jan 23 00:29:34.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.5.8 )
Jan 23 00:29:34.000 [err] Reading config failed--see warnings above.
More users are having the same issue, that their Scallion generated keys cannot be read by the most recent version of TOR.
Any ideas?
**Trac**:
**Username**: larshilseTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33095Don't say "future instances of this warning will be suppressed" when we don't...2020-06-13T15:50:31ZNick MathewsonDon't say "future instances of this warning will be suppressed" when we don't mean it.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://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/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/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/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/32822Make authorities add their own IPv6 address to trusted dir servers2020-06-13T15:49:29ZteorMake authorities add their own IPv6 address to trusted dir serversAuthorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Authorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33104Minor issues when handling ACTIVE control signal2020-06-13T15:50:34ZGeorge KadianakisMinor issues when handling ACTIVE control signalThe ACTIVE control signal is not handled in `control_event_signal()` which results in:
`control_event_signal(): Bug: Unrecognized signal 132 in control_event_signal` messages when it appears.
There is also a mistype in the following co...The ACTIVE control signal is not handled in `control_event_signal()` which results in:
`control_event_signal(): Bug: Unrecognized signal 132 in control_event_signal` messages when it appears.
There is also a mistype in the following comment `/* "SIGACTIVE" counts as ersatz user activity. *`Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32672Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()2020-06-13T15:53:43ZteorReject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allo...We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allow the 0.3.5 series
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
After these dates, we should get arma to test this change, then merge it.
After we merge, we should create a ticket in 0.4.4 to reject 0.4.1.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org