The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:52:37Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27109Tor 0.3.5.0-alpha-dev: [warn] connection_mark_unattached_ap_(): Bug: stream (...2020-06-27T13:52:37ZtraumschuleTor 0.3.5.0-alpha-dev: [warn] connection_mark_unattached_ap_(): Bug: stream (marked at ../src/core/or/connection_edge.c:2605) sending two socks replies?This version is more verbose compared to 0.3.4.5-rc. Two messages stick out:
> Aug 12 20:05:26.000 [warn] Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n"
> Aug 12 20:05:26.000 [warn] connection_mark...This version is more verbose compared to 0.3.4.5-rc. Two messages stick out:
> Aug 12 20:05:26.000 [warn] Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n"
> Aug 12 20:05:26.000 [warn] connection_mark_unattached_ap_(): Bug: stream (marked at ../src/core/or/connection_edge.c:2605) sending two socks replies? (on Tor 0.3.5.0-alpha-dev )
Accessing an offline site tor got loud showing the first line many times:
> Aug 12 17:54:55.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $<scrubbed by reporter> at <scrubbed by reporter> . Retrying on a new circuit.
> Aug 12 17:55:55.000 [notice] Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Since several days I see:
> Aug 12 22:39:00.000 [notice] Bootstrapped 0%: Starting
> Aug 12 22:39:01.000 [warn] Illegal nickname "$2947B29E843D@last-listed" in family lineTor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/27104report intermediate status when building application circuits2020-07-28T22:41:58ZTaylor Yureport intermediate status when building application circuitsDuring bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We shoul...During bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We should make this more granular, probably with intermediate progress at each EXTEND, to make visible when Tor is being slow to build circuits.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27103report initial OR_CONN as the earliest bootstrap phases2020-06-27T13:52:37ZTaylor Yureport initial OR_CONN as the earliest bootstrap phasesWe should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.
When starting to boostrap with existing directory info, there...We should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.
When starting to boostrap with existing directory info, there might not be a need to make an initial connection to a bridge or fallback directory server to download directory info. This means that the initial OR_CONN to a bridge or guard displays on a progress bar as 80%, when in fact a fairly "early" dependency (the initial connection to any OR) could be failing.
Intuitively, starting Tor Browser and seeing the progress bar hang at 80% for a very long time is frustrating and misleading. A user who sees the progress bar hang at at 5% or 10% has a much better idea of what's going on.
Existing directory info can be reflected in the progress bar as a rapid jump after the initial OR_CONN succeeds. This seems less likely to frustrate users.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27102gather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATU...2020-06-27T13:52:37ZTaylor Yugather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum valuesIf we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (legacy/trac#25502), there aren't many numbers remaining to insert between some existing pha...If we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (legacy/trac#25502), there aren't many numbers remaining to insert between some existing phases (if we stick to integers).
We should decouple these so we don't have to cram everything into a tiny portion of the progress bar. It also doesn't make sense to report progress phases that we will never need to execute.
Alternatively, renumber the enums to give us more space toward the beginning of the progress bar.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27100report connection to PT SOCKS proxy separately from OR connection2020-06-27T13:52:37ZTaylor Yureport connection to PT SOCKS proxy separately from OR connectionRight now when acting as a PT client, we don't distinguish between connecting to the SOCKS port of a PT proxy and connecting to the OR that's behind the proxy. This means that we lose some intermediate progress reporting that can help u...Right now when acting as a PT client, we don't distinguish between connecting to the SOCKS port of a PT proxy and connecting to the OR that's behind the proxy. This means that we lose some intermediate progress reporting that can help users understand what might be going wrong.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27096Stop relying on $HOME being set in the unit tests2020-06-27T13:52:37ZteorStop relying on $HOME being set in the unit testsWhen I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME...When I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME environment variable while expanding \"~/.tor\"; defaulting to \"\".\n"
2. warn: "Default DataDirectory is \"~/.tor\". This expands to \"/.tor\", which is probably not what you want. Using \"/usr/local/var/tor\" instead\n"
[validate__uname_for_server FAILED]
```
This test has been around since 0.2.8.1-alpha.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27093Consistently use ${abs_top_srcdir:-../../..} in test_rust.sh2020-06-27T13:52:37ZteorConsistently use ${abs_top_srcdir:-../../..} in test_rust.shSometimes we just use ${abs_top_srcdir}Sometimes we just use ${abs_top_srcdir}Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27091Configure jenkins with CARGO_HOME in a writeable directory2020-06-27T13:52:38ZteorConfigure jenkins with CARGO_HOME in a writeable directoryOr develop a workaround in the tor build scripts.Or develop a workaround in the tor build scripts.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27090Travis: enable lzma and zstd in configure, if available2020-06-27T13:52:38ZteorTravis: enable lzma and zstd in configure, if availableOtherwise, we can break lzma or zstd detection without knowing it.Otherwise, we can break lzma or zstd detection without knowing it.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27089Update to August GeoIP2 database2020-06-27T13:52:38ZKarsten LoesingUpdate to August GeoIP2 database[My geoip-2018-08-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-08-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branch...[My geoip-2018-08-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-08-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27088Pass MODULES_OPTIONS in DISTCHECK_CONFIGURE_FLAGS2020-06-27T13:52:38ZteorPass MODULES_OPTIONS in DISTCHECK_CONFIGURE_FLAGSOops, it seems we missed this one.Oops, it seems we missed this one.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27087Run a single asciidoc build in Travis2020-06-27T13:52:38ZteorRun a single asciidoc build in TravisWe --disable-asciidoc on all our builds, and maybe we shouldn'tWe --disable-asciidoc on all our builds, and maybe we shouldn'tTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27086Write unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_i...2021-09-30T13:45:56ZteorWrite unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_info_from_lspecs()The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27081Don't link pthreads on win32, even if it is present2020-06-27T13:52:38ZNick MathewsonDon't link pthreads on win32, even if it is presentSome mingw setups include an -lpthread, even though we don't use pthreads on windows. Therefore, we should only search for the pthreads functions when we are not building for windows.Some mingw setups include an -lpthread, even though we don't use pthreads on windows. Therefore, we should only search for the pthreads functions when we are not building for windows.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27080bridges fail on Tor 0.3.4.1-alpha and later2020-06-27T13:52:38Zteorbridges fail on Tor 0.3.4.1-alpha and laterWhen I run the chutney bridges-min and bridges+ipv6-min tests on my mac, they fail on every release from 0.3.4.1-alpha through to master (837f11a532). But they succeed on maint-0.3.3, maint-0.3.2, and maint-0.2.9.When I run the chutney bridges-min and bridges+ipv6-min tests on my mac, they fail on every release from 0.3.4.1-alpha through to master (837f11a532). But they succeed on maint-0.3.3, maint-0.3.2, and maint-0.2.9.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27075Typo in control_event_hs_descriptor_content() comment2020-06-27T13:52:39ZNeel Chauhanneel@neelc.orgTypo in control_event_hs_descriptor_content() commentIn this code:
```
/** Send HS_DESC_CONTENT event after completion of a successful fetch from hs
* directory. If <b>hsdir_id_digest</b> is NULL, it is replaced by "UNKNOWN".
* If <b>content</b> is NULL, it is replaced by an empty strin...In this code:
```
/** Send HS_DESC_CONTENT event after completion of a successful fetch from hs
* directory. If <b>hsdir_id_digest</b> is NULL, it is replaced by "UNKNOWN".
* If <b>content</b> is NULL, it is replaced by an empty string. The
* <b>onion_address</b> or <b>desc_id</b> set to NULL will no trigger the
* control event. */
```
The `no trigger` should be `not trigger`.
I will post a PR shortly.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27073conditionvar_timeout intermittently fails on maint-0.3.32020-06-27T13:52:39Zteorconditionvar_timeout intermittently fails on maint-0.3.3util/thread/conditionvar_timeout failed in the last maint-0.3.3 build:
https://travis-ci.org/torproject/tor/builds/411701508
With the following message:
```
util/thread/conditionvar_timeout: [forking]
FAIL src/test/test_threads.c:285...util/thread/conditionvar_timeout failed in the last maint-0.3.3 build:
https://travis-ci.org/torproject/tor/builds/411701508
With the following message:
```
util/thread/conditionvar_timeout: [forking]
FAIL src/test/test_threads.c:285: assert(ti->n_timeouts OP_EQ 2): 1 vs 2Aug 03 13:03:59.190 [err] Error 16 destroying a mutex.
Aug 03 13:03:59.190 [err] tor_assertion_failed_(): Bug: src/common/compat_pthreads.c:172: tor_mutex_uninit: Assertion 0 failed; aborting. (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: Assertion 0 failed in tor_mutex_uninit at src/common/compat_pthreads.c:172. Stack trace: (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(log_backtrace+0x46) [0x55cd7c253ec6] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(tor_assertion_failed_+0xe4) [0x55cd7c294434] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(tor_mutex_uninit+0xa6) [0x55cd7c29d736] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(tor_mutex_free_+0x25) [0x55cd7c262dc5] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(+0x54508a) [0x55cd7bed908a] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(+0x5c840d) [0x55cd7bf5c40d] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(testcase_run_one+0x310) [0x55cd7bf5c7d0] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(tinytest_main+0x1eb) [0x55cd7bf5d58b] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(main+0x4e9) [0x55cd7bbb61b9] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x2b2813951f45] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
Aug 03 13:03:59.191 [err] Bug: ./src/test/test(+0x224fdb) [0x55cd7bbb8fdb] (on Tor 0.3.3.8-dev 2a6c1585b0f13e03)
[Lost connection!]
[conditionvar_timeout FAILED]
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27071Stop using max_width=80 for rustfmt2020-06-27T13:52:39ZteorStop using max_width=80 for rustfmtWe have two options:
* use max_width=79 to match our C coding standards
* use the default max_width=100 to match the Rust defaults and avoid wrapping bugs in rustfmt
For details, see:
https://trac.torproject.org/projects/tor/ticket/2697...We have two options:
* use max_width=79 to match our C coding standards
* use the default max_width=100 to match the Rust defaults and avoid wrapping bugs in rustfmt
For details, see:
https://trac.torproject.org/projects/tor/ticket/26972#comment:2
https://trac.torproject.org/projects/tor/ticket/26972#comment:3Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27066circuit_build_times_update_alpha(): Bug: Could not determine largest build time2022-07-09T17:35:22ZTraccircuit_build_times_update_alpha(): Bug: Could not determine largest build timeThis bug occurs only when v3 hidden services are activated (4 hours after activation v3 services). This was my second test of v3 services and this issue repeated again. Server was running aprox.150 v3 domains.
After below warnings, all ...This bug occurs only when v3 hidden services are activated (4 hours after activation v3 services). This was my second test of v3 services and this issue repeated again. Server was running aprox.150 v3 domains.
After below warnings, all hidden services stoped working.
Could be related to legacy/trac#25733.
```
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 996 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 997 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 998 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 7525ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.3.9 )
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
Aug 07 04:45:49.000 [warn] No valid circuit build time data out of 1000 times, 3 modes, have_timeout=1, 7521.000000ms
...........
```
**Trac**:
**Username**: cstesthttps://gitlab.torproject.org/tpo/core/tor/-/issues/27060Improve coverage in a few high-coverage modules2020-06-27T13:52:39ZNick MathewsonImprove coverage in a few high-coverage modulesI wrote some tests last night while I was burned out on other things.I wrote some tests last night while I was burned out on other things.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson