Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:36:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29017PaddingStatistics should be disabled when ExtraInfoStatistics is 02020-06-13T15:36:26ZteorPaddingStatistics should be disabled when ExtraInfoStatistics is 0The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collec...The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collected on bridges, but the man page says "Relays only."Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28298Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory2020-06-13T15:33:40ZRoger DingledineTor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectoryIn 0.3.2.1-alpha we fixed #22731 (in commit 6fea44c6): we started refusing to start if RunAsDaemon is set and also any of a variety of config options are set to a relative value.
And then in 0.3.3.1-alpha we did commit 192be006, which s...In 0.3.2.1-alpha we fixed #22731 (in commit 6fea44c6): we started refusing to start if RunAsDaemon is set and also any of a variety of config options are set to a relative value.
And then in 0.3.3.1-alpha we did commit 192be006, which split the original options->DataDirectory into a new DataDirectory_option variable.
But warn_about_relative_paths() continues to look at
```
n += warn_if_option_path_is_relative("DataDirectory",options->DataDirectory);
```
and that function is called near the top of options_validate() -- before we call validate_data_directories() which is what populates options->DataDirectory.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28096Windows 8.1 and 10 relays claim to be Windows 82020-06-13T15:33:01ZteorWindows 8.1 and 10 relays claim to be Windows 8In Windows 8.1, Microsoft changed the behaviour of the GetVersionEx function so that it returns 6.2 (Windows 8) for applications without a compatibility manifest. (For applications with a compatibility manifest, it returns the version in...In Windows 8.1, Microsoft changed the behaviour of the GetVersionEx function so that it returns 6.2 (Windows 8) for applications without a compatibility manifest. (For applications with a compatibility manifest, it returns the version in that manifest.)
https://docs.microsoft.com/en-au/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getversionexa
We should change the version returned by Tor's uname function to "Windows 8 or later".Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28027Tor keeps opening circuits while waiting for bridge descriptors2020-06-13T15:32:50ZDavid Gouletdgoulet@torproject.orgTor keeps opening circuits while waiting for bridge descriptorsFrom someone in #tor-dev (`Tovok7`), they migrated an HS from 029 to 034 and some feature broke.
Tor, configured with an HS, starts fine, bootstraps and all is good.
Then, through the control port, `setconf UseBridge=1 Bridge=...` crea...From someone in #tor-dev (`Tovok7`), they migrated an HS from 029 to 034 and some feature broke.
Tor, configured with an HS, starts fine, bootstraps and all is good.
Then, through the control port, `setconf UseBridge=1 Bridge=...` created these logs:
```
2018-10-12 16:18:54.440 I/TorPlugin: Enabling network, using bridges
2018-10-12 16:18:54.456 I/TorPlugin: NOTICE Switching to guard context "bridges" (was using "default")
2018-10-12 16:18:54.608 I/TorPlugin: NOTICE Delaying directory fetches: No running bridges
2018-10-12 16:18:55.031 I/TorPlugin: WARN Error launching circuit to node [scrubbed] for service [scrubbed].
2018-10-12 16:18:55.032 I/TorPlugin: WARN Error launching circuit to node [scrubbed] for service [scrubbed].
2018-10-12 16:18:55.616 I/TorPlugin: OR connection LAUNCHED $02069A3C5362476936B62BA6F5ACC41ABD573A9B
2018-10-12 16:18:55.616 I/TorPlugin: OR connection LAUNCHED $5A2D2F4158D0453E00C7C176978D3F41D69C45DB
2018-10-12 16:18:55.616 I/TorPlugin: OR connection LAUNCHED $B31A7DAD9AACEDDB9915A16617BB8F06BA429D6B
2018-10-12 16:18:55.642 I/TorPlugin: WARN Hidden service [scrubbed] exceeded launch limit with 13 intro points in the last 13 seconds. Intro circuit launches are limited to 10 per 300 seconds.
2018-10-12 16:18:55.642 I/TorPlugin: WARN Service configured in [EPHEMERAL]:
2018-10-12 16:18:55.642 I/TorPlugin: WARN Intro point 0 at [scrubbed]: no circuit
2018-10-12 16:18:55.643 I/TorPlugin: WARN Intro point 1 at [scrubbed]: no circuit
2018-10-12 16:18:55.643 I/TorPlugin: WARN Intro point 2 at [scrubbed]: no circuit
2018-10-12 16:18:55.643 I/TorPlugin: WARN Intro point 3 at [scrubbed]: no circuit
2018-10-12 16:18:55.643 I/TorPlugin: WARN Intro point 4 at [scrubbed]: no circuit
2018-10-12 16:18:56.652 I/TorPlugin: OR connection CONNECTED $02069A3C5362476936B62BA6F5ACC41ABD573A9B
2018-10-12 16:18:57.013 I/TorPlugin: NOTICE new bridge descriptor 'pointingRespighi' (fresh): [scrubbed]
2018-10-12 16:18:57.014 I/TorPlugin: NOTICE Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6457/6457).
2018-10-12 16:18:57.080 I/TorPlugin: OR connection CONNECTED $5A2D2F4158D0453E00C7C176978D3F41D69C45DB
2018-10-12 16:18:57.184 I/TorPlugin: OR connection CONNECTED $B31A7DAD9AACEDDB9915A16617BB8F06BA429D6B
2018-10-12 16:18:57.586 I/TorPlugin: NOTICE new bridge descriptor 'AlliumGermanicus' (fresh): [scrubbed]
2018-10-12 16:18:57.641 I/TorPlugin: NOTICE Bridge 'nonLinearGeometry' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address ([scrubbed]) based on the configured Bridge address.
2018-10-12 16:18:57.641 I/TorPlugin: NOTICE new bridge descriptor 'nonLinearGeometry' (fresh): [scrubbed]
2018-10-12 16:18:57.641 I/TorPlugin: NOTICE We now have enough directory information to build circuits.
2018-10-12 16:19:00.201 I/TorPlugin: NOTICE Tor has successfully opened a circuit. Looks like client functionality is working.
```
It appears that the HS tried to open intro points even though tor didn't have bridge descriptors (guard state got switched).
The HS subsystem is safeguarded by this check (for circuit events):
```
if (router_have_consensus_path() == CONSENSUS_PATH_UNKNOWN ||
!have_completed_a_circuit()) {
return;
}
```
In other words, if we can't open circuits, tor will never proceed with HS service circuits.
The main theory, discussed with armadev, can be deduced with the three first log line:
```
2018-10-12 16:18:54.456 I/TorPlugin: NOTICE Switching to guard context "bridges" (was using "default")
2018-10-12 16:18:54.608 I/TorPlugin: NOTICE Delaying directory fetches: No running bridges
2018-10-12 16:18:55.031 I/TorPlugin: WARN Error launching circuit to node [scrubbed] for service [scrubbed].
```
First line: Guard context switched to bridges. All is good.
Second line: `router_have_minimum_dir_info()` is called from, actually wherever... It is used quite often in many places including our mainloop. The point is that within that function, we do look at `should_delay_dir_fetches()` which is the one creating that notice. However, because 1 was returned, we never went to `update_router_have_minimum_dir_info()` which would have mark that we can't complete circuits (with `note_that_we_maybe_cant_complete_circuits()`).
Third line: Circuit launch failure.
Once the guard context was switched, all circuits were marked as unusable (normal) so the HS service has to rebuild all its intro points but the `have_completed_a_circuit()` was still returning true.
Whatever is the cause, there is a clear issue that when we switch guard context, we should _always_ stop circuit creation until the guard state is usable.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27199panic inside rust extern "C" function is undefined behavior2020-06-13T15:29:38ZTracpanic inside rust extern "C" function is undefined behavior`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac...`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac**:
**Username**: cyberpunksTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27197rust protover accepts excess commas in version strings2020-06-13T15:29:37ZTracrust protover accepts excess commas in version strings
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27073conditionvar_timeout intermittently fails on maint-0.3.32020-06-13T15:29:08Zteorconditionvar_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 Mathewson