Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-07-22T16:20:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26852doc: document Appveyor CI setup2021-07-22T16:20:36Zteordoc: document Appveyor CI setupTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26829torspec: bandwidth file generators should write the file atomically2021-07-22T16:20:36Zteortorspec: bandwidth file generators should write the file atomicallyGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26827torspec: DirAuths should only read the V3BandwidthsFile once per vote2021-07-22T16:20:36Zteortorspec: DirAuths should only read the V3BandwidthsFile once per voteOnce legacy/trac#26797 is implemented, we should document it in the spec.Once legacy/trac#26797 is implemented, we should document it in the spec.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28979Current alpha manual typo authorized_clients2021-07-22T16:20:05ZTracCurrent alpha manual typo authorized_clientsManual text, key word `Client Authorization` mentions `public-key` vs `privkey` for service:
```
To configure client authorization on the service side, the "<HiddenServiceDir>/authorized_clients/" directory needs to exist. Each file in t...Manual text, key word `Client Authorization` mentions `public-key` vs `privkey` for service:
```
To configure client authorization on the service side, the "<HiddenServiceDir>/authorized_clients/" directory needs to exist. Each file in that directory should be suffixed with ".auth" (i.e. "alice.auth"; the file name is irrelevant) and its content format MUST be:
<auth-type>:<key-type>:<base32-encoded-public-key>
The supported <auth-type> are: "descriptor". The supported <key-type> are: "x25519". The <base32-encoded-privkey> is the base32 representation of the raw key bytes only (32 bytes for x25519).
```
rend-spec-v3.txt (4329f00194bdb7adff2c9daa1cf47b09ce4c2a9e) confirms `public-key` instead of `privkey`.
So `privkey` is wrong for service.
**Trac**:
**Username**: FelixixTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29612Update the documentation for ExitRelay2021-07-22T16:19:43ZteorUpdate the documentation for ExitRelayIn legacy/trac#21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.In legacy/trac#21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29135Failing to connect to a v3 onion service with client auth produces really lon...2021-06-23T17:26:03ZpastlyFailing to connect to a v3 onion service with client auth produces really long lines in logIMO Tor shouldn't log the entire descriptor a level warn.
```
Jan 19 16:22:54.692 [warn] Client authorization for requested onion address is invalid. Can't decrypt the descriptor.
Jan 19 16:22:54.692 [warn] Failed to parse received desc...IMO Tor shouldn't log the entire descriptor a level warn.
```
Jan 19 16:22:54.692 [warn] Client authorization for requested onion address is invalid. Can't decrypt the descriptor.
Jan 19 16:22:54.692 [warn] Failed to parse received descriptor "hs-descriptor 3\ndescriptor-lifetime 180\ndescriptor-signing-key-cert\n-----BEGIN ED25519 CERT-----\nAQgABo/UAYFloHvVvnlNECHb5xleCJR [... it keeps going for about 4000 more characters ...]
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29040Tor crashes if ClientOnionAuthDir contains more than one private key for a hi...2021-06-23T17:26:03ZTracTor crashes if ClientOnionAuthDir contains more than one private key for a hidden serviceOS: Arch Linux,
Minimum torrc to reproduce problem:
```
ClientOnionAuthDir /var/lib/tor/auth
```
In /var/lib/tor/auth place a file, for example "key1.auth_private" with:
```
squlj76moawedtuiixydwlzj65323e6k232bpogd4xrrsz4bgcunyqad:des...OS: Arch Linux,
Minimum torrc to reproduce problem:
```
ClientOnionAuthDir /var/lib/tor/auth
```
In /var/lib/tor/auth place a file, for example "key1.auth_private" with:
```
squlj76moawedtuiixydwlzj65323e6k232bpogd4xrrsz4bgcunyqad:descriptor:x25519:XX5M5YQVTGCXPS3E6G6AGOUZYFISOLMSXLD2E3BTL22DUQZLHK4Q
```
then do
```
# cp /var/lib/tor/auth/key1.auth_private /var/lib/tor/auth/key2.auth_private
# tor -f /etc/tor/torrc
```
This yields the traceback:
```
Jan 10 03:57:29.597 [notice] Tor 0.3.5.7 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1a, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7.
Jan 10 03:57:29.598 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 10 03:57:29.598 [notice] Read configuration file "/etc/tor/torrc".
Jan 10 03:57:29.612 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:890: get_options_mutable: Assertion global_options failed; aborting. (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: Assertion global_options failed in get_options_mutable at src/app/config/config.c:890. Stack trace: (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(log_backtrace_impl+0x48) [0x571747260a18] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_assertion_failed_+0x97) [0x57174725bee7] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(get_options_mutable+0x60) [0x5717471dc1d0] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(safe_str_client+0x22) [0x5717471dc552] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(hs_config_client_authorization+0x5a0) [0x571747168e10] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(hs_config_client_auth_all+0x30) [0x5717471fa7f0] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(+0x1798ab) [0x5717471e38ab] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(options_init_from_string+0x364) [0x5717471e7d34] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(options_init_from_torrc+0x376) [0x5717471e82f6] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_init+0x32a) [0x5717470bd7ba] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_run_main+0xcd) [0x5717470be54d] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_main+0x3b) [0x5717470bc62b] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(main+0x1a) [0x5717470bc1ba] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x74f0206a9223] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(_start+0x2e) [0x5717470bc21e] (on Tor 0.3.5.7 )
```
**Trac**:
**Username**: demfloroTor: 0.3.5.x-finalhaxxpophaxxpophttps://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/28970tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_ke...2021-06-23T17:26:03ZTractor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertionIf this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received rel...If this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jan 01 05:31:32.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jan 01 05:31:32.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 01 05:31:32.000 [notice] Tor 0.3.4.9 (git-074ca2e0054fded1) opening log file.
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_send_next_onion_skin+0x372) [0x56345cdfd192] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x78fc3) [0x56345cd92fc3] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:443: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/or/hs_client.c:443. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x352) [0x56345ce7fda2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x33c) [0x56345ce1126c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a0) [0x56345ce31cb0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x56345ce803c9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x28b) [0x56345cd9c2cb] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x791f7) [0x56345cd931f7] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
```
Tor on Linux. Is it related to legacy/trac#27471 or legacy/trac#19926?
**Trac**:
**Username**: torcrashTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28669Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc2021-06-23T17:26:02ZtraumschuleBug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_descAfter suspend tor 0.4.0.0-alpha-dev-20181118T011041Z-1~d99.buster+1 had this issue:
```
Nov 26 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
Nov 26 10:37:43.000 [notice] {GENERAL} Your system clock just jumped 35475 s...After suspend tor 0.4.0.0-alpha-dev-20181118T011041Z-1~d99.buster+1 had this issue:
```
Nov 26 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
Nov 26 10:37:43.000 [notice] {GENERAL} Your system clock just jumped 35475 seconds forward; assuming established circuits no longer work.
Nov 26 10:38:38.000 [warn] {CIRC} Failed to find node for hop #1 of our path. Discarding this circuit.
Nov 26 10:38:39.000 [notice] {CIRC} Our circuit 0 (id: 202) died due to an invalid selected path, purpose Hidden service client: Fetching HS descriptor. This may be a torrc configuration issue, or a bug.
Nov 26 10:41:00.000 [warn] {BUG} 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 )
Nov 26 10:41:01.000 [warn] {BUG} 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 )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace_impl+0x5e) [0x6d4c4e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x6d042d] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(hs_client_dir_info_changed+0xce) [0x5da00e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(router_dir_info_changed+0x34) [0x5ffbc4] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x41f) [0x5f7fef] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(connection_dir_reached_eof+0xf7f) [0x5c006f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x829) [0x53c679] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(+0x568f9) [0x5428f9] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(+0x2091b) [0xb7e3291b] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7e333b1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x672ab0] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0xc0) [0x543d40] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_run_main+0x141a) [0x530f9a] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x3f) [0x52e35f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x32) [0x52ded2] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb774c9a1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(+0x41f2e) [0x52df2e] (on Tor 0.4.0.0-alpha-dev )
<repeated once>
Nov 26 10:41:11.000 [notice] {APP} Tried for 120 seconds to get a connection to 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up. (waiting for rendezvous desc)
Nov 26 10:41:36.000 [warn] {BUG} 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 )
Nov 26 10:41:36.000 [warn] {BUG} 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 )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace_impl+0x5e) [0x6d4c4e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x6d042d] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(hs_client_dir_info_changed+0xce) [0x5da00e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(router_dir_info_changed+0x34) [0x5ffbc4] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(microdescs_add_list_to_cache+0x2bc) [0x5f1fec] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(microdescs_add_to_cache+0x2ce) [0x5f23ce] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(connection_dir_reached_eof+0x1666) [0x5c0756] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x829) [0x53c679] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(+0x568f9) [0x5428f9] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(+0x2091b) [0xb7e3291b] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7e333b1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x672ab0] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0xc0) [0x543d40] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_run_main+0x141a) [0x530f9a] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x3f) [0x52e35f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x32) [0x52ded2] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb774c9a1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(+0x41f2e) [0x52df2e] (on Tor 0.4.0.0-alpha-dev )
<repeated once>
Nov 26 10:42:38.000 [notice] {APP} Tried for 120 seconds to get a connection to jukrlvyhgguiedqswc5lehrag2fjunfktouuhi4wozxhb6heyzvshuyd:5222. Giving up. (waiting for rendezvous desc)
```
- jukrlvyhgguiedqswc5lehrag2fjunfktouuhi4wozxhb6heyzvshuyd is Riseup's XMPP server
- 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd is Riseup's mail server
Didn't have the chance to reproduce it yet.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30454hs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAY2021-06-23T17:24:34ZDavid Gouletdgoulet@torproject.orghs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAYI'm not sure how it happens because this code got in almost at the same time but the introduction ACK status code are not synchronized with what trunnel can parse which can lead to the intro point hard asserting() if it ever tries to sen...I'm not sure how it happens because this code got in almost at the same time but the introduction ACK status code are not synchronized with what trunnel can parse which can lead to the intro point hard asserting() if it ever tries to send the status code: `HS_INTRO_ACK_STATUS_CANT_RELAY = 0x0003`.
See `cell_introduce1.trunnel`, it does not handle status code `0x0003`:
```
u16 status IN [0x0000, 0x0001, 0x0002];
```
Fortunately for us, it can NOT happen with the current code. The only call site is here:
```
/* Relay the cell to the service on its intro circuit with an INTRODUCE2
* cell which is the same exact payload. */
if (relay_send_command_from_edge(CONTROL_CELL_ID, TO_CIRCUIT(service_circ),
RELAY_COMMAND_INTRODUCE2,
(char *) request, request_len, NULL)) {
log_warn(LD_PROTOCOL, "Unable to send INTRODUCE2 cell to the service.");
/* Inform the client that we can't relay the cell. */
status = HS_INTRO_ACK_STATUS_CANT_RELAY;
goto send_ack;
}
```
... and turns out that `relay_send_command_from_edge()` can *NEVER* return anything else than 0 (we've audited all the currently supported versions, they all behave the same there).
This prevents tor from asserting in `send_introduce_ack_cell()` with:
```
/* A wrong status is a very bad code flow error as this value is controlled
* by the code in this file and not an external input. This means we use a
* code that is not known by the trunnel ABI. */
tor_assert(ret == 0);
```
There are a series of things to fix here.
1. The status code should be defined within the trunnel file and ONLY that ABI should be used. In short, `hs_intro_ack_status_t` should disappear in favor of the one that needs to be defined with trunnel. Side node, same must be done for: `hs_intro_auth_key_type_t`
2. Because clients won't be able to know what `HS_INTRO_ACK_STATUS_CANT_RELAY` is, we should remove it at once for now since it was/is never used.
3. We should add a default case to the trunnel definition so if we ever extend this later, tor will not explode or simply fail to parse the cell.
4. We should conduct an audit of the `tor_assert()` in the HS code and replace them with non fatal ones if possible.
We got very lucky here because else it would have been an easy remote relay crash so (4) is very important. One lesson is also to *NEVER* duplicate any values defined in a trunnel file. Always use the defined ABI of that trunnel spec.
End note, this was found by legacy/trac#15516 branch which re-used this error code and during testing, the intro point relay exploded.
All this got into 0.3.0.1-alpha.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_i...During my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points()` function which showed me 4 intro points.
I haven't found out why but one feature of HS is that we launch `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and the first one to finish are picked.
It appears that more than the defined value can finish at the same time and will be picked.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31408torrc : ClientOnionAuthDir after include directives breaks client to v2 services2021-06-23T17:24:15ZTractorrc : ClientOnionAuthDir after include directives breaks client to v2 servicesIf I append these two statements to torrc, in this order :
ClientOnionAuthDir /etc/tor/auth/
%include /etc/tor/torrc.d/
and restart tor.service, I can connect to 1 × v3 and 4 × v2 services, within seconds.
But if I reverse their order...If I append these two statements to torrc, in this order :
ClientOnionAuthDir /etc/tor/auth/
%include /etc/tor/torrc.d/
and restart tor.service, I can connect to 1 × v3 and 4 × v2 services, within seconds.
But if I reverse their order ( %include first ), I can only connect to the v3 service -- all other connections will eventually time out.
In man, I missed to find any recommandation about ordering these statements.
( this is on Debian Stretch with torproject's stretch repo )
Thanks!
**Trac**:
**Username**: xahoTor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/27310Tor 0.3.4.7-rc fails to upload v3 hidden service descriptors2021-06-21T11:13:05ZtraumschuleTor 0.3.4.7-rc fails to upload v3 hidden service descriptorsThis instance has several hidden services configured and v2 onions are reachable with this version of Tor.
Starting Tor 0.3.4.7-rc (git-6809bbe766dbf6b3) i got following warning 32 times:
> {REND} Uploading hidden service descriptor: h...This instance has several hidden services configured and v2 onions are reachable with this version of Tor.
Starting Tor 0.3.4.7-rc (git-6809bbe766dbf6b3) i got following warning 32 times:
> {REND} Uploading hidden service descriptor: http status 400 ("Invalid HS descriptor. Rejected.") response from dirserver '$address'. Malformed hidden service descriptor?
I wonder if files created by the previously used Tor 0.3.5.0-alpha-dev are incompatible with 0.3.4.7-rc.
Will attach a scrubbed info log later, debug log is available on demand.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29875Going from obfs4 to snowflake using the Tor Network Settings from the Torbutt...2021-02-25T15:32:26ZcypherpunksGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't workGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work, i.e. nothing happens and no website can load, if I restart the browser then snowflake works perfectlyGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work, i.e. nothing happens and no website can load, if I restart the browser then snowflake works perfectlyTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26876tor.real fails to start on macOS 10.92021-02-25T15:32:26ZMark Smithtor.real fails to start on macOS 10.9While trying to test Snowflake on a macOS 10.9 system (for legacy/trac#26251), I encountered a different issue: tor.real fails to start. The error is:
```
dyld: lazy symbol binding failed: Symbol not found: _mach_approximate_time
Refer...While trying to test Snowflake on a macOS 10.9 system (for legacy/trac#26251), I encountered a different issue: tor.real fails to start. The error is:
```
dyld: lazy symbol binding failed: Symbol not found: _mach_approximate_time
Referenced from: /Users/.../Desktop/Tor/TB nightly 2018-07-18/Tor Browser.app/Contents/MacOS/Tor/tor.real
Expected in: /usr/lib/libSystem.B.dylib
```
At this point I don't know if this is a core tor bug or if it is caused by something in the Tor Browser 8.x build process.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26200Bandwidth List format specification: add KeyValues counting errors in Bandwid...2021-02-18T15:34:40ZjugaBandwidth List format specification: add KeyValues counting errors in Bandwidth Linesthey could be useful to understand which relays fail to be measured and why, to solve legacy/trac#16559
So far we thought to add:
- success
- error_stream
- error_circuit
- error_misc
Edit: to solve legacy/trac#16559they could be useful to understand which relays fail to be measured and why, to solve legacy/trac#16559
So far we thought to add:
- success
- error_stream
- error_circuit
- error_misc
Edit: to solve legacy/trac#16559Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26155Bandwidth file Timestamp is the latest scanner result, not the file creation ...2021-02-18T15:34:40ZteorBandwidth file Timestamp is the latest scanner result, not the file creation timeThe bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://g...The bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n409
(This is buggy in small networks, because the unmeasured node scanner may end up in a state where is never has any nodes to scan. But we are not fixing torflow bugs.)
Here's how I suggest we fix the spec issue:
Replace the initial Timestamp with:
```
Timestamp NL
[At start, exactly once.]
The Unix Epoch time in seconds of the most recent scanner result.
If there are multiple scanners which can fail independently, implementations
SHOULD take the most recent timestamp from each scanner and use the
oldest value. This ensures all the scanners continue running.
If there are scanners that do not run continuously, they SHOULD be excluded
from the timestamp calculation,
It does not follow the KeyValue format for backwards
compatibility with version 1.0.0.
```
Add a file creation date:
```
"file_created=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
when the file was created.
This Line has been added in version 1.1.0 of this specification.
```
Add a latest bandwidth in human-readable format:
```
"latest_bandwidth=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
of the most recent scanner result.
This time MUST be identical to the initial Timestamp line.
This duplicate value is included to make the format easier for people
to read.
This Line has been added in version 1.1.0 of this specification.
```Tor: 0.3.5.x-finalteorteorhttps://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/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 Kadianakis