The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-10-19T12:31:25Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40352Nonauthoritative directory does not accept posted server descriptors2021-10-19T12:31:25ZTommaso GragnatoNonauthoritative directory does not accept posted server descriptors```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107...```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107.47.215](https://metrics.torproject.org/rs.html#details/45E9240AD4ECE01793A1977C1260503B2C2C861F) is running 0.4.6 alpha and does not understand descriptors for v2 onions. Hence the 400.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40266#note_2724898
Should this be handled gracefully? What's the phase out plan?Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40534Cannot open URLs on command line with Tor Browser 10.52021-07-22T17:47:34ZcypherpunksCannot open URLs on command line with Tor Browser 10.5Tor browser appears to no longer open URLs when passed as arguments on the command line, which it used to do.
### Symptoms:
* $ /path/to/start-tor-browser https://url.com used to launch url.com
* **EXAMPLE COMMAND** $ /home/me/.start-...Tor browser appears to no longer open URLs when passed as arguments on the command line, which it used to do.
### Symptoms:
* $ /path/to/start-tor-browser https://url.com used to launch url.com
* **EXAMPLE COMMAND** $ /home/me/.start-tor-browser duckduckgo.com
* The above used to launch duckduckgo.com, but with the new version of tor browser (10.5) it merely connects to tor and remains on the tor browser start page
Apologies if this is a duplicate issue; I did look for one already but did not find anythingTor Browser: 11.0 Issues with previous releaserichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40509relay: Stop advertising HSv2 protocol version2022-02-05T21:30:38ZDavid Gouletdgoulet@torproject.orgrelay: Stop advertising HSv2 protocol versionWe just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could...We just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could for any alt-implementation out there that uses those for v2.
Essentially, relay protocol version should be set to:
- `HSIntro=4-5` -> removing `3` which is v2 specific.
- `HSDir=2` -> removing `1` which is v2 specific.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40493fallbackdirs: Update list for October 2021 releases2021-11-14T12:41:19ZDavid Gouletdgoulet@torproject.orgfallbackdirs: Update list for October 2021 releasesWe are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.We are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40476hs-v2: Remove support for HSv2 on stable versions2021-10-19T15:03:12ZDavid Gouletdgoulet@torproject.orghs-v2: Remove support for HSv2 on stable versionsNow that the HSv2 has been removed from the code base in 0.4.6.x series, we now need to proceed onto the next phase which is to eliminate it from the network.
We'll do this by removing the entry points into the HSv2 code relay side so:
...Now that the HSv2 has been removed from the code base in 0.4.6.x series, we now need to proceed onto the next phase which is to eliminate it from the network.
We'll do this by removing the entry points into the HSv2 code relay side so:
- HSDir will stop accepting or serving v2 descriptors
- Introduction points wills top allowing introductions for v2.
- For Rendezvous points, we'll stop allowing it by refusing the TAP connection from the service side.
For client side:
- Disallow v2 service creation and client connections.
With these guards, we should be good with the removal of v2 in the network. We need this patch in 035 and 045 (the last two stable release we maintain with v2 support).Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34303Find out why onion service measurements have gotten slower2022-07-07T00:49:01ZKarsten 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.Tor: 0.3.5.x-finalKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33346Seccomp soft fail (no write) in 0.4.2.62021-01-28T17:58:13ZTracSeccomp soft fail (no write) in 0.4.2.6I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has p...I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has permissions to write to this directory - fine with Sandbox 0.
Log:
```
# cat /var/log/tor/log
Feb 16 00:46:56.000 [notice] Tor 0.4.2.6 opening new log file.
Feb 16 00:46:56.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Feb 16 00:46:57.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Feb 16 00:46:57.000 [notice] Bootstrapped 0% (starting): Starting
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-certs": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs.new": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-descriptors" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-extrainfo" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [notice] Starting with guard context "default"
Feb 16 00:46:58.000 [warn] Couldn't open "/var/lib/tor/data/state.tmp" (/var/lib/tor/data/state) for writing: Operation not permitted
Feb 16 00:46:58.000 [warn] Unable to write state to file "/var/lib/tor/data/state"; will try again later
Feb 16 00:46:58.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 16 00:46:58.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Feb 16 00:46:58.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Feb 16 00:46:58.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/unverified-microdesc-consensus.tmp" (/var/lib/tor/data/unverified-microdesc-consensus) for writing: Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Feb 16 00:46:59.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/cached-certs.tmp" (/var/lib/tor/data/cached-certs) for writing: Operation not permitted
Feb 16 00:46:59.000 [warn] Error writing certificates to disk.
Feb 16 00:46:59.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
```
#### Appendix
##### Environment
```
Tor: 0.4.2.6
OS: Gentoo arm64
Hardware: Raspberry Pi 4
Kernel: 4.19.102-v8+ (RPi base)
```
##### Other info
When running 0.4.2.5, I experienced a crash with seccomp (possibly related to legacy/trac#27315)?
```
# tor
Feb 16 00:37:42.963 [notice] Tor 0.4.2.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 16 00:37:42.963 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 16 00:37:42.963 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 00:37:42.966 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 16 00:37:42.966 [notice] Opened Socks listener on 127.0.0.1:9050
============================================================ T= 1581813463
(Sandbox) Caught a bad syscall attempt (syscall unlinkat)
tor(+0x1cd714)[0x5571820714]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7f8bde0658]
/lib64/libc.so.6(unlink+0x30)[0x7f8b8058d8]
tor(run_tor_main_loop+0x74)[0x55716ae874]
tor(tor_run_main+0x11c)[0x55716aead4]
tor(tor_main+0x50)[0x55716ad458]
tor(main+0x24)[0x55716acf74]
/lib64/libc.so.6(__libc_start_main+0xe4)[0x7f8b758cac]
tor(+0x59fd0)[0x55716acfd0]
```
**Trac**:
**Username**: subjectfrostingTor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33131Bug: buf->datalen >= 0x7fffffff2021-01-28T18:01: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.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28992Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion ...2021-06-23T17:26:03ZtraumschuleBug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.(likely follow-up of legacy/trac#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/feat...(likely follow-up of legacy/trac#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.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40581prometheus issues label name "port" is not unique: invalid sample when scraping2022-03-25T19:26:31ZAlex Xuprometheus issues label name "port" is not unique: invalid sample when scrapingexample output:
```
tor_hs_app_write_bytes_total{onion="duwq3shurnywtxq5z76dbcy7gbqyjgel4vzauxupuc4v773tiyxif5qd",port="80",port="443"} 1000
```
while I am new to Prometheus, my understanding is that each sample of a metric can have a...example output:
```
tor_hs_app_write_bytes_total{onion="duwq3shurnywtxq5z76dbcy7gbqyjgel4vzauxupuc4v773tiyxif5qd",port="80",port="443"} 1000
```
while I am new to Prometheus, my understanding is that each sample of a metric can have at most one value per label. therefore, `port="80",port="443"` is invalid. i think this makes sense in this context: either tor is able to count the bytes per port, in which case there should be two lines, one with `port="80"`, and one with `port="443"`, or tor can only count the bytes per service, in which case there should be one line and no port labels.
assuming the former is true, I think https://gitlab.torproject.org/tpo/core/tor/-/blob/455471835da35d8ee64e6a2c0a70acb89a003bf4/src/feature/hs/hs_metrics.c#L46-59 should look like:
```
if (base_metrics[i].port_as_label && service->config.ports) {
SMARTLIST_FOREACH_BEGIN(service->config.ports,
const hs_port_config_t *, p) {
metrics_store_entry_t *entry =
metrics_store_add(store, base_metrics[i].type, base_metrics[i].name,
base_metrics[i].help);
/* Add labels to the entry. */
metrics_store_entry_add_label(entry,
metrics_format_label("onion", service->onion_address));
metrics_store_entry_add_label(entry,
metrics_format_label("port", port_to_str(p->virtual_port)));
} SMARTLIST_FOREACH_END(p);
} else {
metrics_store_entry_t *entry =
metrics_store_add(store, base_metrics[i].type, base_metrics[i].name,
base_metrics[i].help);
/* Add labels to the entry. */
metrics_store_entry_add_label(entry,
metrics_format_label("onion", service->onion_address));
}
```
possibly with refactoring, and maybe adjustment of the condition, although I'm not sure it is allowed to have an onion service without ports? I have not submitted this as an MR because I have not tested it at all.
strangely, however, the case of multiple ports per service seems to already be handled at https://gitlab.torproject.org/tpo/core/tor/-/blob/455471835da35d8ee64e6a2c0a70acb89a003bf4/src/feature/hs/hs_metrics.c#L80-91, it is just not initialized properly. possibly this change was intended during development and not completed?Tor: 0.4.7.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40544Update URL in warning message when initiating Tor2022-01-18T18:19:49ZdonutsUpdate URL in warning message when initiating TorA [forum user has reported](https://forum.torproject.net/t/tor-s-warning-linking-to-website-is-broken/1749) receiving the following message in terminal when initiating Tor:
> When you start Tor in the terminal, you get the warning `Tor ...A [forum user has reported](https://forum.torproject.net/t/tor-s-warning-linking-to-website-is-broken/1749) receiving the following message in terminal when initiating Tor:
> When you start Tor in the terminal, you get the warning `Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning`. However, https://www.torproject.org/download/download#warning redirects to https://www.torproject.org/download/#warning, and there’s no #warning to jump to, and there’s no warning to read.
I wonder if this URL is an artifact of the old website, since I don't recall ever seeing a warning section on torproject.org/download. Gus informs me the correct link on the new website should be the following instead:
- https://support.torproject.org/faq/staying-anonymous/Tor: 0.4.7.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40527Remove DNS timeout from overload general2023-02-07T10:24:10ZDavid Gouletdgoulet@torproject.orgRemove DNS timeout from overload generalRelated to our investigation in:
https://gitlab.torproject.org/tpo/network-health/team/-/issues/139
This is also tied to https://gitlab.torproject.org/tpo/core/tor/-/issues/40312 which will lower the Tor DNS timeout from 5 seconds to 1...Related to our investigation in:
https://gitlab.torproject.org/tpo/network-health/team/-/issues/139
This is also tied to https://gitlab.torproject.org/tpo/core/tor/-/issues/40312 which will lower the Tor DNS timeout from 5 seconds to 1 seconds.
This needs to be backported to 0.4.6 because it is creating a lot of confusion for relay operators and inaccurate warnings.Tor: 0.4.7.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40491relay: Overload state for DNS timeout error should be done after X% failure2023-02-07T10:24:31ZDavid Gouletdgoulet@torproject.orgrelay: Overload state for DNS timeout error should be done after X% failureWe currently get into an overload state if an Exit only hits _once_ a DNS timeout error which is way too low. Lets get into an overload state only if we have 1% of all our DNS requests end up timing out.
To do this properly, we should a...We currently get into an overload state if an Exit only hits _once_ a DNS timeout error which is way too low. Lets get into an overload state only if we have 1% of all our DNS requests end up timing out.
To do this properly, we should accumulate DNS requests for some time (or some number of requests) before assessing if we've reached the X% threshold. And we should use a timeframe before assessing a certain threshold.
After discussing with @mikeperry on IRC, we think doing consensus parameters controlling `X% over Y minutes` would be the way to do this. And we can set the defaults to X=1 and Y=10 for a 1% DNS errors over 10 minutes.
And every, 10 minutes, that total number of DNS requests needs to be reset so previous period don't affect the subsequent periods.
We need to backport this to 0.4.6 else we'll have a big problem on the network where almost all Exits will start reporting overload state once they migrate to 0.4.6+Tor: 0.4.7.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41307[win/mac] font whitelist typos2022-10-18T12:23:48ZThorin[win/mac] font whitelist typosnote: I only checked windows, so far, but assume mac also has these bundled
whitelist includes
```
Noto Sans Tifinagh AgrawImazighen
Noto Sans Tifinagh RhissaIxa
Noto Serif Nyiakeng Puachue Hmong
```
but these fonts are nowhere to be f...note: I only checked windows, so far, but assume mac also has these bundled
whitelist includes
```
Noto Sans Tifinagh AgrawImazighen
Noto Sans Tifinagh RhissaIxa
Noto Serif Nyiakeng Puachue Hmong
```
but these fonts are nowhere to be found in web content: https://arkenfox.github.io/TZP/tests/fontlists.html (sorry, mac/linux lists not updated) - https://github.com/arkenfox/TZP/commit/3d92e09939efa7a08ad515d651b6627149b3b5d7
![test](/uploads/41b5e642033eafa796d230357b56f9c6/test.png)
Note: there are 122 bundled fonts (121 + twemoji), but I have listed 125 (I added the three correct font names), so with the current whitelist it will show 6 not found.
The correct names are
```
Noto Sans Tifinagh Agraw Imazighen
Noto Sans Tifinagh Rhissa Ixa
Noto Serif Hmong Nyiakeng
```
If you modify the whitelist to reflect the correct names, then only the incorrect names are no longer found (and I can remove them from the test)
NOTE: I have not looked fully, but were any of these three added to any font.name* prefs in any platform?
@pierov , also `Font` labelSponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40624Change placeholder bridge addresses to make snowflake and meek work with Reac...2023-05-02T02:18:50ZDavid Fifielddcf@torproject.orgChange placeholder bridge addresses to make snowflake and meek work with ReachableAddresses/FascistFirewallChange the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are ...Change the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are not based on making a single connection to a single endpoint; for that reason, Snowflake and meek use "placeholder" addresses, currently 192.0.2.3:1 and 192.0.2.2:2 respectively. However, this causes a problem with ReachableAddresses/FascistFirewall (i.e. the "This computer goes through a firewall that only allows connections to certain ports" setting). tor doesn't know that these transports do not actually connect to the placeholder addresses; all it sees is that port 1 and port 2 are not on the permitted list, so it considers the bridge unusable (tpo/core/tor#19487):
```
[NOTICE] Bridge at '192.0.2.2:2' isn't reachable by our firewall policy. Asking bridge authority instead.
```
The anti-censorship team proposes to set the port of placeholder addresses to 80, so that Snowflake and meek will be usable even when ReachableAddresses/FascistFirewall is set.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40159#note_2834570
> We currently assign placeholder addresses using the format
>
> > 192.0.2.<var>t</var>:<var>n</var>
>
> where <var>t</var> indicates the transport (1=flashproxy, 2=meek, 3=snowflake) and <var>n</var> is a counter if there are multiple bridge lines for single transport (currently that doesn't happen, but in the past we had :1 for meek-google, :2 for meek-amazon, :3 for meek-azure; and tpo/anti-censorship/pluggable-transports/snowflake#28651 will add a second snowflake bridge).
>
> If we switch to a hardcoded port of 80, there will not be separate places to encode <var>t</var> and <var>n</var>. But we could encode them both into one byte, using 4 bits for <var>t</var> and 4 bits for <var>n</var>:
>
> > 192.0.2.(16(<var>n</var>−1)+<var>t</var>):80
The team discussed this at the 2022-09-08 meeting.
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-09-08-15.58.log.html#l-66
```
16:26:30 <meskio> "A new format for placeholder addresses in PT bridge lines"
16:26:37 <dcf1> okay, quick note about placeholder addresses
16:27:12 <dcf1> we have been using placeholder addresses with incrementing port numbers :1, :2, :3, etc., because tor requires all PT bridges to have different IP:port, or it gets them confused
16:27:56 <dcf1> this causes a problem when tor is configured with ReachableAddresses or FascistFirewall, because tor thinks the PT is going to try to actually make a TCP connection to those placeholder addresses
16:28:22 <dcf1> and it says "port 1 is not one of the ports permitted by FascistFirewall, therefore I will not attempt this bridge connection"
16:28:35 <dcf1> imo it's a bug in core tor, but it's WONTFIX for years now
16:29:15 <meskio> it might not get fixed until arti
16:29:23 <dcf1> so the proposal is to move this counter into the IP address and always use port 80 for placeholder addresses, to make them more likely to work with ReachableAddresses and FascistFirewall
16:30:49 <dcf1> Way back in flash proxy, which also needed a placeholder address, I tried to make the placeholder look as different from an actual usable IP address as possible, to reduce confusion
16:31:20 <dcf1> since then, the placeholders have been slowly morphing to look more and more like real IP addresses :)
16:31:38 <dcf1> the progression was something like:
16:31:57 <dcf1> 0.0.0.0:0 <- no good, tor uses the all-zero address as a sentinel internally
16:32:09 <dcf1> 0.0.0.1:1 <- no good, 0.0.0.X is used by SOCKS
16:32:35 <dcf1> 0.0.1.0:1 <- we used this for a while, but it ran into problems with 0/8 being considered "internal" by tor
16:32:59 <dcf1> 192.0.2.1:1 <- what we use now, using a special non-routable IP range reserved for documentation
16:33:13 <dcf1> 192.0.2.1:80 <- new proposal
...
16:39:19 <dcf1> okay well I will propose a merge request with the 192.0.2.(16(n−1)+t):80 format, it's good enough for our needs for now
```Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40585Prune the manual more2022-10-12T18:31:41ZPier Angelo VendramePrune the manual moreWe have had an increase in TBB size, and it's partly due to the manual.
We should remove webfonts because they are not even rendered (7.9MB uncompressed), there are not minimized JS and CSS, and we should see if we can remove some image...We have had an increase in TBB size, and it's partly due to the manual.
We should remove webfonts because they are not even rendered (7.9MB uncompressed), there are not minimized JS and CSS, and we should see if we can remove some images.
We can remove what we don't need with the script that packs the manual (it just copies the static files).Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40549Test failure in protover.c (main)2022-12-10T17:58:55ZDavid Gouletdgoulet@torproject.orgTest failure in protover.c (main)protover/supported_protocols:
FAIL /builds/dgoulet/tor/src/test/test_protover.c:427: assert(protocol_list_supports_protocol(supported_protocols, PRT_HSINTRO, PROTOVER_HS_INTRO_V2))
[supported_protocols FAILED]
Due to latest protove...protover/supported_protocols:
FAIL /builds/dgoulet/tor/src/test/test_protover.c:427: assert(protocol_list_supports_protocol(supported_protocols, PRT_HSINTRO, PROTOVER_HS_INTRO_V2))
[supported_protocols FAILED]
Due to latest protover change where `HSIntro` went to minimum of `4`.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40515pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state ne...2022-04-14T13:39:03ZRoger Dingledinepathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open.On my Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589, I can induce this log message:
```
Nov 11 07:07:06.365 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently ...On my Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589, I can induce this log message:
```
Nov 11 07:07:06.365 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
Nov 11 07:07:06.392 [notice] pathbias_mark_use_success(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
Nov 11 07:07:06.393 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
```
The way I do it is by going into the controller, and doing an
```
extendcircuit 0 moria1,CalyxInstitute14
mapaddress 10.10.10.11=128.31.0.34.0011BD2485AD45D984EC4159C88FC066E5E3300E.exit
```
and then from my shell, doing a
```
torify telnet 10.10.10.11 80
```
I successfully connect via that exit to the desired webserver. But the circuit that Tor made via extendcircuit hasn't set whatever flags or the like it was expecting to have set.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40494tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: dire...2021-11-03T13:55:05Zsamip537tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed;### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the follo...### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the following contents:
```
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 443
ORPort [2001:DB8::1]:443
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB
AccountingMax 5 TB
AccountingStart month 3 15:00
DirPort [2001:DB8::1]:80
ExitPolicy reject *:*
```
5. Have it crash after 3-10 minutes from bandwidth self-test.
### What is the current bug behavior?
The whole Tor client crashes when set with DirPort with IPv6 address in brackets followed by port.
### What is the expected behavior?
It would not crash.
### Environment
- Which version of Tor are you using? 0.4.5.10
- Which operating system are you using? Debian 11, in an LXC container
- Which installation method did you use? Distribution package
### Relevant logs and/or screenshots
```
Oct 22 06:42:35 torrelay systemd[1]: Started Anonymizing overlay network for TCP.
Oct 22 06:42:35 torrelay Tor[6069]: Signaled readiness to systemd
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 5% (conn): Connecting to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Opening Socks listener on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opened Socks listener connection (ready) on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opening Control listener on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Opened Control listener connection (ready) on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address.
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 10% (conn_done): Connected to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 14% (handshake): Handshaking with a relay
Oct 22 06:42:36 torrelay Tor[6069]: External address seen and suggested by a directory authority: <snip>
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Oct 22 06:42:37 torrelay Tor[6069]: Bootstrapped 100% (done): Done
Oct 22 06:43:36 torrelay Tor[6069]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv4 ORPort <snip>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv6 ORPort [2001:DB8::1]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Self-testing indicates your ORPort [2001:DB8::1]:443 is reachable from the outside. Excellent.
Oct 22 06:45:37 torrelay Tor[6069]: Self-testing indicates your ORPort <snip>:443 is reachable from the outside. Excellent.
Oct 22 06:45:39 torrelay Tor[6069]: Performing bandwidth self-test...done.
Oct 22 06:48:37 torrelay Tor[6069]: tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed; aborting. (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: Tor 0.4.5.10: Assertion or_addr_port->port || dir_addr_port->port failed in directory_initiate_request at ../src/feature/dirclient/dirclient.c:1257: . Stack trace: (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0x557a907880] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_assertion_failed_+0x124) [0x557a914364] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(directory_initiate_request+0x714) [0x557a9d5424] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(router_do_reachability_checks+0x184) [0x557a8d27b8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(connection_dir_reached_eof+0x13cc) [0x557a9d783c] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x1993e4) [0x557a9a93e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x68570) [0x557a878570] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x234e4) [0x7f9e42e4e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x50c) [0x7f9e42ef84] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(do_main_loop+0xec) [0x557a8799e0] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_run_main+0x1c0) [0x557a8751b4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_main+0x54) [0x557a871734] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(main+0x20) [0x557a871220] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0x7f9dd5c218] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x612a8) [0x557a8712a8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Main process exited, code=killed, status=6/ABRT
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Failed with result 'signal'.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Oct 22 06:48:37 torrelay systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
```
### Possible fixesTor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40472Be more particular about limit argument to smartlist_split_string()2022-10-11T23:39:35ZNick MathewsonBe more particular about limit argument to smartlist_split_string()OSS-Fuzz claims that there's a ridiculously slow runtime for calling "diff-apply" when the line with the hashes has a whole bunch of fields in it.
That's because we call `smartlist_split_string()` with a final argument of "0", which mea...OSS-Fuzz claims that there's a ridiculously slow runtime for calling "diff-apply" when the line with the hashes has a whole bunch of fields in it.
That's because we call `smartlist_split_string()` with a final argument of "0", which means "no limit on the number of pieces to split this string into". That results in a whole bunch of allocations, which are slow under the AddressSanitizer that the fuzzer uses. I don't think this one is actually a great CPU DOS vector in the wild: malloc() isn't that slow when you aren't using asan.
But nonetheless we should go through all our calls to smartlist_split_string(), see which ones don't have a limit, and maybe impose a limit on them.
The ~Backport label on this ticket is tentative: we might want to backport important fixes we find here, if we think they might lead to problems down the line.Tor: 0.4.5.x-post-stable