Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33673Use the right DLLs and pkg-config path on Appveyor2020-06-13T15:52:26ZteorUse the right DLLs and pkg-config path on AppveyorWe want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.We want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-13T15:52:21ZteorAppveyor: 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 #32449, #28574, #28399 and #25942....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 #32449, #28574, #28399 and #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 Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33491tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal...2020-06-13T15:51:55ZTractor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC ...Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
```
Mar 1 13:53:33 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
```
**Trac**:
**Username**: sjcjonkerTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33212Warning in protover.rs making CI fail.2020-06-13T15:50:50ZNick MathewsonWarning in protover.rs making CI fail.It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33195Require IPv6 tests in Travis CI2020-06-13T15:50:47ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32792Copy chutney CI diagnostics to Tor's chutney job2020-06-13T15:49:19ZteorCopy chutney CI diagnostics to Tor's chutney jobIn #32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.In #32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32449Appveyor: OpenSSL version mismatch in unit tests, 2019 edition2020-06-13T15:52:21ZteorAppveyor: OpenSSL version mismatch in unit tests, 2019 edition```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:237: OpenSSL library version 1.1.1d did not begin with header version 1.1.1c.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/builds/28...```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:237: OpenSSL library version 1.1.1d did not begin with header version 1.1.1c.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/builds/28757237/job/ul9m0fnglaqtw3oy?fullLog=true#L3511Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32407Fix crash when calling --dump-config with failing set_options2020-06-13T15:48:00ZNick MathewsonFix crash when calling --dump-config with failing set_optionsIt appears that our cleanup code hits an assertion failure when we have been called with --dump-config and a set of options that fails in set_options().It appears that our cleanup code hits an assertion failure when we have been called with --dump-config and a set of options that fails in set_options().Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32242Travis: Enable zstd2020-06-13T15:47:23ZteorTravis: Enable zstdWhen we make chutney work on Bionic or Xenial (#32240), we can enable zstd on Travis.
We could have a different package list for Bionic and Trusty, but that kind of duplication is error-prone.When we make chutney work on Bionic or Xenial (#32240), we can enable zstd on Travis.
We could have a different package list for Bionic and Trusty, but that kind of duplication is error-prone.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32086Try Visual Studio 2019 image in appveyor2020-06-13T15:46:37ZteorTry Visual Studio 2019 image in appveyorWe can't afford the build time for 3 images, so we should probably replace 2017.We can't afford the build time for 3 images, so we should probably replace 2017.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32058mainloop: make periodic events restartable2020-06-13T15:46:33Zteormainloop: make periodic events restartableWhen we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.When we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31939log spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf...2020-06-13T15:46:17ZTaylor Yulog spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Nonfatal assert log spamming as seen in #31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```...Nonfatal assert log spamming as seen in #31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```
(I assume the `#` in the middle of `INT_MAX` is a paste/transcription artifact, but then again it might not be.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31884Define ExecuteBash in the Appveyor error block2020-06-13T15:46:07ZteorDefine ExecuteBash in the Appveyor error blockWhen Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mw...When Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mws73je9sihmfnTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31837Make test_rebind.py more robust2020-06-13T15:45:56ZteorMake test_rebind.py more robust* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during #...* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during #30901.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31571Add the tor version and a newline to raw_assert()2020-06-13T15:44:55ZteorAdd the tor version and a newline to raw_assert()We're missing a newline and the tor version in the logs for #31570.We're missing a newline and the tor version in the logs for #31570.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31554Restrict "make test-stem" to tests that actually use tor2020-06-13T15:44:51ZteorRestrict "make test-stem" to tests that actually use torIn #30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.In #30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2020-06-13T15:46:40ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of #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...During my testing of #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/legacy/trac/-/issues/31408torrc : ClientOnionAuthDir after include directives breaks client to v2 services2020-06-13T15:44:17ZTractorrc : 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/legacy/trac/-/issues/31008Typographical error on tor man pages help command2020-06-13T15:43:08ZAadi BajpaiTypographical error on tor man pages help commandman tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New ...man tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New users may get confused if they don't know the -h/--help convention.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30916assert in dimap_add_entry()2020-06-13T15:42:42ZDavid Gouletdgoulet@torproject.orgassert in dimap_add_entry()From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "defau...From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "default"
============================================================ T= 1560854012
INTERNAL ERROR: Raw assertion failed at ../src/lib/ctime/di_ops.c:179: !
old_val/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x55a17b410943]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x86)[0x55a17b410fd6]
/usr/bin/tor(dimap_add_entry+0xa0)[0x55a17b411ba0]
/usr/bin/tor(construct_ntor_key_map+0x69)[0x55a17b357969]
/usr/bin/tor(server_onion_keys_new+0x4d)[0x55a17b39f4dd]
/usr/bin/tor(+0x66e27)[0x55a17b287e27]
/usr/bin/tor(threadpool_new+0x18b)[0x55a17b3b3f0b]
/usr/bin/tor(cpu_init+0x9d)[0x55a17b28828d]
/usr/bin/tor(run_tor_main_loop+0x136)[0x55a17b27a496]
/usr/bin/tor(tor_run_main+0x1215)[0x55a17b27b935]
/usr/bin/tor(tor_main+0x3a)[0x55a17b278a8a]
/usr/bin/tor(main+0x19)[0x55a17b278609]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffb901ba2e1]
/usr/bin/tor(_start+0x2a)[0x55a17b27865a]
Jun 18 13:33:33.000 [notice] Tor 0.3.5.8 opening log file.
```
It appears that tor tried to add the same value in the `di_digest256_map_t` twice.
Logs indicate 0.3.5.8Tor: 0.3.5.x-finalNick MathewsonNick Mathewson