Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:47:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-27T13:47:57ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33781DocTor chokes on malformed dirreq-stats-end line2021-01-28T17:53:37ZGeorg KoppenDocTor chokes on malformed dirreq-stats-end lineI started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-en...I started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-end 2020-03-30 21:23:53 (86400 s)
```
Upon inspection it turns out that the lines in question contain an `^M` at the end which is likely to cause the problem.
It's not clear to me where the bug exactly is, meaning where it should get fixed. I thought maybe `stem` is not lenient enough here and teor suggested it's a `tor` bug. Thus, I am filing it here. Attached is the extra info descriptor DocTor is choking on. For some reason not all lines end on a `^M` which is kind of surprising.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33780hs-v3: Change to log notice the registration of an OB instance2021-06-23T17:22:41ZDavid Gouletdgoulet@torproject.orghs-v3: Change to log notice the registration of an OB instanceChange this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Change this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33779Fix incorrect PublishHidServDescriptors value in logs2021-06-23T17:22:41ZteorFix incorrect PublishHidServDescriptors value in logsThis code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not...This code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not publishing descriptor. "
"PublishHidServDescriptors is set to 1.",
safe_str_client(service->onion_address));
goto end;
}
```
I'll leave it to dgoulet and asn to fix, and decide how far it needs to be backported.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33778TestingTorNetwork options in the man page are out of date2021-07-22T16:18:20ZoparaTestingTorNetwork options in the man page are out of dateA few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 's...A few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 'seconds' as well. I only fixed the ones that were relevant to `TestingTorNetwork`, but there are probably others as well. Will add a PR shortly.
In addition, many of the options that are of type `INTERVAL` use different units in the man page. For example:
```
ShutdownWaitLength NUM
V3AuthVotingInterval N minutes|hours
TestingV3AuthVotingStartOffset N seconds|minutes|hours
DormantClientTimeout N minutes|hours|days|weeks
```
Since these are all of type `INTERVAL`, is there a reason why these units are different when all of them support any unit in `unitparse.c` (seconds, minutes, hours, days, weeks)? One reason could be that some options have lower bounds (for example `V3AuthVotingInterval` must be greater than 300 seconds which is of the order of minutes), but the user can just specify 300 seconds rather than 5 minutes.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33767consider using a GitHub mirror for tor-rust-dependencies2021-02-05T21:09:48ZTaylor Yuconsider using a GitHub mirror for tor-rust-dependenciesDuring a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted abou...During a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted about three of them, ignoring the builds that were obsolete due to more recent changes.) I think this has happened before due to transient network faults.
We should consider making a GitHub mirror of the tor-rust-dependencies repository, and use that instead of the more canonical git.torproject.org location during Travis builds. (I'm guessing that the github.com repositories are very likely reachable if a Travis build starts successfully.) We might lose the ability to use the default git submodule setup done by Travis, though.
```
$ git submodule update --init --recursive
Submodule 'src/ext/rust' (https://git.torproject.org/tor-rust-dependencies) registered for path 'src/ext/rust'
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust'. Retry scheduled
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust' a second time, aborting
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33762OnionService v3 running as onionbalance backend fails to reload failing with ...2021-06-23T17:22:41Zs7rOnionService v3 running as onionbalance backend fails to reload failing with get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed.When you do a **reload** on a Tor process that is running an onion service v3 as an onionbalance backend instance (with `HiddenServiceOnionBalanceInstance 1` in torrc), it fails to come up, making the backend onion service **unavailable*...When you do a **reload** on a Tor process that is running an onion service v3 as an onionbalance backend instance (with `HiddenServiceOnionBalanceInstance 1` in torrc), it fails to come up, making the backend onion service **unavailable** while not exiting the Tor process entirely. The only thing that makes it heal is a _restart_' of the process.
It can be triggered any time you **reload** (SIGHUP) a Tor process with an onion service running with `HiddenServiceOnionBalanceInstance 1`. This is Tor 0.4.4.0-alpha-dev-20200327T132009Z-1~d10.buster+1 from deb.tpo nightly master.
Here is the full stack trace:
```
Mar 29 15:59:12.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Mar 29 15:59:12.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 29 15:59:12.000 [notice] Read configuration file "/etc/tor/torrc".
Mar 29 15:59:12.000 [info] config_generic_service(): HiddenServiceDir="/var/lib/tor/ob-hs". Configuring...
Mar 29 15:59:12.000 [info] config_generic_service(): HiddenServicePort=80 127.0.0.1:80 for "/var/lib/tor/ob-hs"
Mar 29 15:59:12.000 [info] tor_getpwnam(): Caching new entry debian-tor for debian-tor
Mar 29 15:59:12.000 [info] helper_parse_uint64(): HiddenServiceOnionBalanceInstance was parsed to 1
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
Mar 29 15:59:12.000 [notice] Tor 0.4.4.0-alpha-dev opening log file.
Mar 29 16:00:42.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987: get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!service->ob_subcreds) failed in get_subcredential_for_handling_intro2_cell at ../src/feature/hs/hs_circuit.c:987. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x56) [0x558eb518fee6] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x16c) [0x558eb518b0ec] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(hs_circ_handle_introduce2+0x5eb) [0x558eb5091e3b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(hs_service_receive_introduce2+0xc3) [0x558eb50a53d3] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x1be) [0x558eb50e672e] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xbe368) [0x558eb502e368] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xbf1c5) [0x558eb502f1c5] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x2b4) [0x558eb5030a44] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x2c8) [0x558eb5013788] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x4eb) [0x558eb4ff2f0b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xac5ca) [0x558eb501c5ca] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0xa92) [0x558eb4fe03a2] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0x75609) [0x558eb4fe5609] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f34833269ba] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f3483327537] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xff) [0x558eb4fe688f] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10b5) [0x558eb4fd3bc5] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x558eb4fd12ca] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x558eb4fd0e89] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3482c0809b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x558eb4fd0eda] (on Tor 0.4.4.0-alpha-dev )
```
One instance has 26 such stack traces across a time period of 6 mins and 54 seconds and the other one 32 such stack traces across a time period of 4 mins and 28 seconds.
----
While we are at this, `config_generic_service()` , `tor_getpwnam()`, `helper_parse_uint64()` and `ob_option_parse()` report **[info]** level logs in a **Log notice file** configured Tor instance, is this normal?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33759recent_measurements_excluded_few_count is used twice in bandwidth spec2020-06-27T13:47:58ZGeorg Koppenrecent_measurements_excluded_few_count is used twice in bandwidth specWhile going over the spec again during review for legacy/trac#30905 I stumbled over `recent_measurements_excluded_few_count` being used twice. The second instance should be `relay_recent_measurements_excluded_few_count` instead.While going over the spec again during review for legacy/trac#30905 I stumbled over `recent_measurements_excluded_few_count` being used twice. The second instance should be `relay_recent_measurements_excluded_few_count` instead.Tor: 0.4.4.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33747If the ExtORPort doesn't report an external IP address, Tor won't apply rate ...2020-10-15T16:30:29ZRoger DingledineIf the ExtORPort doesn't report an external IP address, Tor won't apply rate limiting or account for bandwidth on that connectionIn the early days of Tor pluggable transports, on the server side you would run the bridge and the server component of the pluggable transport next to each other, and from Tor's perspective the connection would come in from 127.0.0.1 (i....In the early days of Tor pluggable transports, on the server side you would run the bridge and the server component of the pluggable transport next to each other, and from Tor's perspective the connection would come in from 127.0.0.1 (i.e. "from the obfs4 server sitting next to the bridge"). And because Tor doesn't apply rate limiting to connections from localhost, it wouldn't rate limit connections coming in via the pluggable transport, and also it wouldn't count bytes to/from that connection in its extrainfo counts or in its BW controller events.
We improved the situation by inventing the "ExtORPort", or "Extended ORPort", which has a quick handshake at the front that specifies e.g. what address the connection is "really" from, and then Tor treats the or_connection_t as though it came directly from that external address. So far so good.
But if the ExtORPort handshake doesn't specify an address, then Tor defaults to 127.0.0.1 (or wherever the server-side of the PT actually is), meaning it resumes having the "no rate limit, no bandwidth accounting" original behavior. That's no good, and we've hit this bug in practice because of a Snowflake bug (legacy/trac#33157).
I propose three fixes:
(A) In our documentation for setting up bridges, make it clear that setting an ExtORPort to go with your server-side PT is not just for user count statistics, but it is needed if you want rate limiting and proper bandwidth accounting and reporting.
(B) We could go farther here and tell server-side pluggable transports to demand an ExtORPort from Tor (i.e. refuse to start if you aren't given one). I think this is a good idea, but let me know if you see downsides.
(C) Do something smart with connections over the ExtORPort if they show up without a USERADDR command. I don't know of any concrete reasons why picking a dummy non-internal probably-not-routable address like 255.255.255.255 would break things, but also this is a fine opportunity to do something that doesn't leave future generations shaking their fist at us. For example: add a flag to connection_t called is_external_for_rate_limiting (or a catchier paint color name) where if it's 1 then yes it's external, and if it's 0 then you have to go check the address like before. And then eventually we'd transition more of Tor to use that flag, rather than recomputing whether to apply rate limiting many times over the course of a connection's lifetime.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33703Improving HS availability under DoS (master ticket)2022-10-11T23:39:34ZGeorge KadianakisImproving HS availability under DoS (master ticket)This is the master ticket for organizing work under this topic.This is the master ticket for organizing work under this topic.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33702RSA_get0_d could not be located in the dynamic link library tor.exe2023-05-31T18:44:10ZTracRSA_get0_d could not be located in the dynamic link library tor.exeOS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browse...OS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browser\Browser\TorBrowser\Tor\tor.exe
**Trac**:
**Username**: ner0https://gitlab.torproject.org/tpo/core/tor/-/issues/33687Create rotating DNS DoH/DoT server list option Trr Core Tor2020-07-29T14:43:15ZcypherpunksCreate rotating DNS DoH/DoT server list option Trr Core TorReference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Reference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33686Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled2020-06-27T13:48:00ZcypherpunksTor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabledI get this output from the terminal only when Sandbox 1 is enabled and it did not happen on earlier versions:
Mar 21 21:07:21.000 [notice] Bootstrapped 0% (starting): Starting
Mar 21 21:10:10.000 [notice] Starting with guard context "...I get this output from the terminal only when Sandbox 1 is enabled and it did not happen on earlier versions:
Mar 21 21:07:21.000 [notice] Bootstrapped 0% (starting): Starting
Mar 21 21:10:10.000 [notice] Starting with guard context "default"
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:353: workerthread_new: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at workerthread_new at src/lib/evloop/workqueue.c:353. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x12b) [0x5ae6b0] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [err] Can't launch worker thread.
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:519: threadpool_start_threads: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at threadpool_start_threads at src/lib/evloop/workqueue.c:519. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x15b) [0x5ae6e0] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:563: threadpool_new: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at threadpool_new at src/lib/evloop/workqueue.c:563. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x183) [0x5ae708] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
============================================================ T= 1584825010
Tor 0.4.2.7 died: Caught signal 11
tor(+0x19631a)[0x60031a]
tor(threadpool_register_reply_event+0x19)[0x5ae80e]
tor(threadpool_register_reply_event+0x19)[0x5ae80e]
tor(cpu_init+0x61)[0x4be676]
tor(run_tor_main_loop+0x9f)[0x4b3064]
tor(tor_run_main+0xb85)[0x4b3f16]
tor(tor_main+0x23)[0x4b1f98]
tor(main+0x13)[0x4b1c24]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97)[0xb694b524]
[1]+ Illegal instruction tor -f torrcTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-27T13:48:01ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2023-05-30T18:39:08ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org2023-05-31https://gitlab.torproject.org/tpo/core/tor/-/issues/33668--disable-module-relay yields to a Bug:2020-06-27T13:48:01Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33651Suspicious "fetched this many bytes" counts from #327202020-06-27T13:48:01ZRoger DingledineSuspicious "fetched this many bytes" counts from #32720Following legacy/trac#32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've s...Following legacy/trac#32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 166.22 MB and received 5.25 GB.
Mar 17 23:52:49.178 [notice] While bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] While not bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] Average packaged cell fullness: 52.843%. TLS write overhead: 3%
Mar 18 17:01:52.177 [notice] Your system clock just jumped 44387 seconds forward; assuming established circuits no longer work.
Mar 18 18:12:33.010 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 166.25 MB and received 5.25 GB.
Mar 18 18:12:33.011 [notice] While bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] While not bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] Average packaged cell fullness: 52.898%. TLS write overhead: 3%
Mar 19 00:12:33.013 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 166.26 MB and received 5.25 GB.
Mar 19 00:12:33.013 [notice] While bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] While not bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] Average packaged cell fullness: 52.953%. TLS write overhead: 3%
```
I'm running
```
Tor 0.4.4.0-alpha-dev (git-d4595b344a1a3254) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
```
It is surprising to me that I have the same number while bootstrapping and while not bootstrapping, and that number doesn't seem to go up.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33646Wrong list of enabled modules2021-07-05T11:27:26ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: legacy/trac#32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-27T13:48:02ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#285...It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#28574, legacy/trac#28399 and legacy/trac#25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson