Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:12:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23233Unexpected BUG violation in hsv3 decriptor decoding2020-06-13T15:12:42ZhaxxpopUnexpected BUG violation in hsv3 decriptor decoding
As you can see in hs_descriptor.c
```
/* Find the start of signature. */
sig_start = tor_memstr(encoded_desc, encoded_len, "\n" str_signature);
/* Getting here means the token parsing worked for the signature so if we
* can't ...
As you can see in hs_descriptor.c
```
/* Find the start of signature. */
sig_start = tor_memstr(encoded_desc, encoded_len, "\n" str_signature);
/* Getting here means the token parsing worked for the signature so if we
* can't find the start of the signature, we have a code flow issue. */
if (BUG(!sig_start)) {
goto err;
}
```
str_signature is "signature", so, if you send the "\n signature" (like in the attachment) instead of "\nsignature" tor_memstr will return null and violate `BUG(!sig_start)`
I suggest that we should just remove BUG and let it be `if (!sig_start) {`Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23155Double free on error in config_process_include2020-06-13T15:12:35ZNick MathewsonDouble free on error in config_process_includeTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23139memory leak in consdiffmgr.c2020-06-13T15:12:32ZRoger Dingledinememory leak in consdiffmgr.cRunning a relay under valgrind:
```
==46685== 37,152 (288 direct, 36,864 indirect) bytes in 18 blocks are definitely lost in loss record 76 of 81
==46685== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==46685== by 0x295047: tor_m...Running a relay under valgrind:
```
==46685== 37,152 (288 direct, 36,864 indirect) bytes in 18 blocks are definitely lost in loss record 76 of 81
==46685== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==46685== by 0x295047: tor_malloc_ (util.c:150)
==46685== by 0x28691E: smartlist_new (container.c:34)
==46685== by 0x223173: store_multiple (consdiffmgr.c:1150)
==46685== by 0x22351C: consensus_compress_worker_replyfn (consdiffmgr.c:1714)
==46685== by 0x29B871: replyqueue_process (workqueue.c:634)
==46685== by 0x2F28D3: event_persist_closure (in /home/tord2/tor/src/or/tor)
==46685== by 0x2F2BE4: event_process_active_single_queue (in /home/tord2/tor/src/or/tor)
==46685== by 0x2F325F: event_process_active (in /home/tord2/tor/src/or/tor)
==46685== by 0x2F39C3: event_base_loop (in /home/tord2/tor/src/or/tor)
==46685== by 0x155CAC: do_main_loop (main.c:2607)
==46685== by 0x156DEC: tor_main (main.c:3756)
```
Sure enough, `consdiffmgr_ensure_space_for_files()` looks like it has a
```
smartlist_t *objects = smartlist_new();
```
and `objects` is never freed in this function.
Looks like the bug arrived in commit 7a096427.
This said, that's a lot of indirect lost bytes too. Is there something *in* the smartlist that gets leaked too? I didn't find anything obvious.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23077Channelpadding tests rely on actual time; can fail2020-06-13T15:12:12ZNick MathewsonChannelpadding tests rely on actual time; can failWe're seeing an intermittent failure on Jenkins:
```
14:46:53 channelpadding/channelpadding_consensus: [forking]
14:46:53 FAIL ../tor/src/test/test_channelpadding.c:445: assert(decision OP_EQ CHANNELPADDING_PADDING_SCHEDULED): 4 vs 2...We're seeing an intermittent failure on Jenkins:
```
14:46:53 channelpadding/channelpadding_consensus: [forking]
14:46:53 FAIL ../tor/src/test/test_channelpadding.c:445: assert(decision OP_EQ CHANNELPADDING_PADDING_SCHEDULED): 4 vs 2
14:46:53 [channelpadding_consensus FAILED]
```
Looking at the code, it seems that the underlying channelpadding code depends on the actual time (from `monotime_coarse_abosolute_*()`) to make its decisions. But we aren't doing anything to mock those functions from inside the test case, which may be making the outcome of this test dependent on the code running fast enough.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/23071test_hs_ntor.sh fails with recent pysha32020-06-13T15:12:11ZNick Mathewsontest_hs_ntor.sh fails with recent pysha3Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23053Memory leak of unix_socket_path when validating multiple unix sockets2020-06-13T15:12:05ZNick MathewsonMemory leak of unix_socket_path when validating multiple unix socketsThis is CID 1415725This is CID 1415725Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22934PADDING cells can't be sent immediately after a VERSIONS cell2020-06-13T15:11:48ZteorPADDING cells can't be sent immediately after a VERSIONS cellWhen I send a VERSIONS cell and a PADDING cell in the same socket write, Tor 0.3.0.9 closes the connection:
```
Jul 15 19:55:43.000 [info] channel_register: Channel 0x7f848276e300 (global ID 207) in state opening (1) registered with no i...When I send a VERSIONS cell and a PADDING cell in the same socket write, Tor 0.3.0.9 closes the connection:
```
Jul 15 19:55:43.000 [info] channel_register: Channel 0x7f848276e300 (global ID 207) in state opening (1) registered with no identity digest
Jul 15 19:55:43.000 [info] channel_tls_process_versions_cell: Negotiated version 3 with [scrubbed]:58001; Sending cells: VERSIONS CERTS AUTH_CHALLENGE NETINFO
Jul 15 19:55:43.000 [info] channel_tls_handle_cell: Received unexpected cell command 0 in chan state opening / conn state handshaking (Tor, v3 handshake); closing the connection.
Jul 15 19:55:43.000 [info] conn_close_if_marked: Conn (addr [scrubbed], fd 9, type OR, state 7) marked, but wants to flush 2033 bytes. (Marked at src/or/connection_or.c:1338)
Jul 15 19:55:43.000 [info] conn_close_if_marked: We stalled too much while trying to write 2033 bytes to address [scrubbed]. If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 9, type OR, state 7, marked at src/or/connection_or.c:1338).
```
It doesn't matter if I send a VPADDING cell before the padding cell.
But the tor spec says:
```
When this handshake is in use, the first cell must
be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed to
intervene besides those specified, except for PADDING and VPADDING cells.
```
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n482Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22927zstd tests fail with libzstd 1.3.02020-06-13T15:11:46Zteorzstd tests fail with libzstd 1.3.0When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures...When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures:
```
buffer/compress/zstd: [forking]
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
[compress/zstd FAILED]
...
util/compress_concat/zstd:
FAIL src/test/test_util.c:2414: assert(r OP_EQ 0): -1 vs 0
[compress_concat/zstd FAILED]
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22892Compilation fails when openssl 1.1.0 and libscrypt are both detected2020-06-13T15:11:33ZNick MathewsonCompilation fails when openssl 1.1.0 and libscrypt are both detectedIn 706c44a6ce0bbeee51c800521a3199d76e1dcd96 I removed some includes as unneeded. Apparently they were actually used to cross-check openssl's scrypt against libscrypt in the case that both were detected.In 706c44a6ce0bbeee51c800521a3199d76e1dcd96 I removed some includes as unneeded. Apparently they were actually used to cross-check openssl's scrypt against libscrypt in the case that both were detected.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22883Bridge unavailable during differential consensus update2020-06-13T15:11:30ZTracBridge unavailable during differential consensus updateAfter updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all av...After updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all available cpu (more than 90% on average - with no corresponding traffic for clients) and files are updated in /var/lib/tor/diff-cache directory.
(For example, if I launch a TorBrowser using this bridge during such an update, it remains blocked before opening the Welcome window, and the corresponding client tor process remains blocked after "Bootstrapped 90%: Establishing a Tor circuit", for 10 minutes or more).
So I had to downgrade to 0.3.0.9, so that my bridge doesn't become unavailable for a total of several hours per day.
May I suggest that an option make it possible to choose between the new differential update mode and the traditional one?
First, this would be necessary for some (like me) to keep following new Tor versions long term.
And even on more powerful platforms, and even if a better handling of priorities could make it possible for main Tor thread to remain available on Pi, Tor relay operators might want to make different choices between minimizing bandwidth for consensus transfer or minimizing cpu usage, and hence power consumption. (Please think of the Planet globally, and not only of the network ;) )
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22879Tor fails to start (assert)2020-06-13T15:11:28ZTracTor fails to start (assert)Compiled tor from source, tried both the Gitlab and the tarball from this site, both 0.3.0.9. When I try to run tor it exits at ~80% with the following error message
Machine : Linux t1 2.6.32-042stab120.5 #1 SMP Tue Oct 25 22:31:12 MSK...Compiled tor from source, tried both the Gitlab and the tarball from this site, both 0.3.0.9. When I try to run tor it exits at ~80% with the following error message
Machine : Linux t1 2.6.32-042stab120.5 #1 SMP Tue Oct 25 22:31:12 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux
OpenSSL: tor-0.3.0.9# openssl version
OpenSSL 1.0.1f 6 Jan 2014
```
Jul 11 02:59:45.000 [err] tor_assertion_failed_(): Bug: src/or/shared_random.c:922: sr_generate_our_commit: Assertion my_rsa_cert failed; aborting. (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: Assertion my_rsa_cert failed in sr_generate_our_commit at src/or/shared_random.c:922. Stack trace: (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(log_backtrace+0x42) [0x7f1b32ea7d02] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(tor_assertion_failed_+0x94) [0x7f1b32ebf4b4] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(sr_generate_our_commit+0x40e) [0x7f1b32db013e] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(sr_state_update+0x245) [0x7f1b32db2c55] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(sr_state_init+0x8c) [0x7f1b32db310c] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(do_main_loop+0x312) [0x7f1b32d9b832] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(tor_main+0x1c25) [0x7f1b32d9ee05] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(main+0x19) [0x7f1b32d97299] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f1b317c8f45] (on Tor 0.3.0.9 22b3bf094e327093)
Jul 11 02:59:45.000 [err] Bug: tor(+0x462eb) [0x7f1b32d972eb] (on Tor 0.3.0.9 22b3bf094e327093)
```
**Trac**:
**Username**: ramTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22873more details about maint- vs release- vs master2020-06-13T15:11:27Zpastlymore details about maint- vs release- vs masterUpdate doc/HACKING/CodingStandards.md with some more advice regarding how to branch off of tor.
See git-branch-use on my gitweb repo.Update doc/HACKING/CodingStandards.md with some more advice regarding how to branch off of tor.
See git-branch-use on my gitweb repo.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22870consdiff test fails on OS X2020-06-13T15:11:26Zpastlyconsdiff test fails on OS XSee gitweb user/pastly/tor.git branch ticket22870
strcmp on most platforms returns -1 for "less than 0" and 1 for "more than 0" but +/- 1 isn't required. Today I learned that OS X is one of those platforms that follows the standard but ...See gitweb user/pastly/tor.git branch ticket22870
strcmp on most platforms returns -1 for "less than 0" and 1 for "more than 0" but +/- 1 isn't required. Today I learned that OS X is one of those platforms that follows the standard but not the convention.
Introduced in tor-0.3.1.1-alphaTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22830Problems with building with --enable-rust with RUST_DEPENDENCIES2020-06-13T15:11:21ZIsis LovecruftProblems with building with --enable-rust with RUST_DEPENDENCIESFrom #22816, Chelsea and I realised that there are some problems when trying to build the Rust code currently in tor in "offline mode" with `RUST_DEPENDENCIES` specifying a directory where the dependencies should live. (I.e. building wit...From #22816, Chelsea and I realised that there are some problems when trying to build the Rust code currently in tor in "offline mode" with `RUST_DEPENDENCIES` specifying a directory where the dependencies should live. (I.e. building with `RUST_DEPENDENCIES='path_to_dependencies_directory' ./configure --enable-rust` as noted on [the wiki page](https://trac.torproject.org/projects/tor/wiki/RustInTor) on building with Rust.)
So one problem was that I had a relative path for `RUST_DEPENDENCIES` (now noted on the wiki that it must be the full path).
There are other problems though. Cargo expects a lot of structure to be there (basically everything that would normally be in `~/.cargo` needs to be in the directory we're giving it as our `HOME` or `CARGO_HOME`). While we _could_ write some scripts or something to basically reimplement a bunch of cargo functionality to set all that up, it's kind of non-trivial and it seems like a potential maintainability hazard. Another, even worse way (IMHO) around this would be to say, "if you use `RUST_DEPENDENCIES` then the entire build doesn't use cargo, but instead calls rustc with the flags that cargo would have." (This seems even less maintainable, because then we have two distinct ways to compile the Rust code.)
Instead, I think a solution which is potentially better than either of those would be to say something like: "If you want to use `RUST_DEPENDENCIES`, you have to run the following first, which will use cargo to get the dependencies, and then you can re-use the directory it produces offline by specifying it in `RUST_DEPENDENCIES."
```
mkdir path_to_dependencies_directory
cd src/rust
rm .cargo/config
CARGO_HOME="/whatever/full/path_to_dependencies_directory/.cargo" cargo update
CARGO_HOME="/whatever/full/path_to_dependencies_directory/.cargo" cargo fetch
```
After this initial set up of the directories which cargo is expecting the normal offline build should be conducted, and instead of passing `HOME` to cargo, we should pass `CARGO_HOME` as is used above.Tor: 0.3.1.x-finalChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/22819Choice of compressors seems to be suboptimal2020-06-13T15:11:16Zyurivict271Choice of compressors seems to be suboptimalThe latest tor-devel uses 2 compression libraries: zstd and lzma.
Based on this graph https://raw.githubusercontent.com/facebook/zstd/dev/doc/images/DCspeed5.png lzma only slightly exceeds zstd in a small range of values.
Why didn't yo...The latest tor-devel uses 2 compression libraries: zstd and lzma.
Based on this graph https://raw.githubusercontent.com/facebook/zstd/dev/doc/images/DCspeed5.png lzma only slightly exceeds zstd in a small range of values.
Why didn't you choose lz4? Based on this lz4 description https://github.com/lz4/lz4 it offers an advantage in a different range of values: towards the lower left corner of the first graph. lz4 can compress with lower ratio but with much higher speed.
If you want to choose several libraries, doesn't it make sense to cover a wider range of values, rather than choose two libraries that cover a similar range?
zstd + lz4 seems to be a better choice.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22789Tor 0.3.1.4-alpha crash on OpenBSD-current2020-06-13T15:11:01ZfredzupyTor 0.3.1.4-alpha crash on OpenBSD-currentHi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next !...Hi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Things I've done before :
$ ./configure
$ make
$ make test
$ doas src/or/tor -f /etc/tor/torrc
Then put some load on the Tor process with some random http request.
Logs with context :
Jul 1 05:06:02 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:03 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:04 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:07 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:11 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:12 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:15 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: Tried for 133 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:18 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:18 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:19 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:21 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:26 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:27 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:30 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:34 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:36 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:42 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:45 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22779choose_good_entry_server() is no longer used to choose entry guards2020-06-13T15:10:57Zteorchoose_good_entry_server() is no longer used to choose entry guardschoose_good_entry_server() says:
```
* If <b>state</b> is NULL, we're choosing a router to serve as an entry
* guard, not for any particular circuit.
```
But in 0.3.0 and later, we use guardsets to choose entry guards.
(And we use thi...choose_good_entry_server() says:
```
* If <b>state</b> is NULL, we're choosing a router to serve as an entry
* guard, not for any particular circuit.
```
But in 0.3.0 and later, we use guardsets to choose entry guards.
(And we use this function to choose individual entries.)
We should:
* fix the comment,
* check for NULL state (and do what?), and
* make sure that guard selection and entry selection doesn't get out of sync. (I think we're ok here, but I don't understand the new guard code very well.)Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22752Assertion failure in consensus_cache_entry_handle_get on Windows2020-06-13T15:10:52ZAlexander Færøyahf@torproject.orgAssertion failure in consensus_cache_entry_handle_get on WindowsWe've received a bug report on execdir@ with a bug in Tor 0.3.1.3-alpha (dc47d936d47ffc25).
The following log snippet was attached:
```
24 02:42:42.645 [Warning] Unable to unlink "S:/PortableApps/TorBrowser/Browser/TorBrowser/Data/Tor\...We've received a bug report on execdir@ with a bug in Tor 0.3.1.3-alpha (dc47d936d47ffc25).
The following log snippet was attached:
```
24 02:42:42.645 [Warning] Unable to unlink "S:/PortableApps/TorBrowser/Browser/TorBrowser/Data/Tor\\diff-cache/1011"
24 02:42:42.645 [Warning] tor_bug_occurred_(): Bug: consdiffmgr.c:1285: store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
24 02:42:42.645 [Warning] Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at consdiffmgr.c:1285. (Stack trace not available) (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
24 02:47:50.583 [Error] tor_assertion_failed_(): Bug: conscache.c:521: consensus_cache_entry_handle_get: Assertion ref failed; aborting. (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
24 02:47:50.583 [Error] Bug: Assertion ref failed in consensus_cache_entry_handle_get at conscache.c:521. (Stack trace not available) (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22751LZMA coder causes crash when the sandbox is enabled2020-06-13T15:10:51ZAlexander Færøyahf@torproject.orgLZMA coder causes crash when the sandbox is enabledWhile doing the measurements for Sponsor 4 I noticed that Tor instances running as relays or authorities would sometimes crash when the sandbox is enabled.
This is due to the `MALLOC_MP_LIM` value in `sandbox.c`, which is currently set ...While doing the measurements for Sponsor 4 I noticed that Tor instances running as relays or authorities would sometimes crash when the sandbox is enabled.
This is due to the `MALLOC_MP_LIM` value in `sandbox.c`, which is currently set to 16 MB, being too low. We limit our LZMA coder to only use 16 MB, but the coder allocates some additional data other than its internal buffer, which leads to the crash.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22742torspec should say when tor's event buffer limit was removed2020-06-13T15:10:48Zteortorspec should say when tor's event buffer limit was removedThere is no limit now, it was removed in:
```
5.2. Don't let the buffer get too big.
If you ask for lots of events, and 16MB of them queue up on the buffer,
the Tor process will close the socket.
```
This happened in #16480 or mayb...There is no limit now, it was removed in:
```
5.2. Don't let the buffer get too big.
If you ask for lots of events, and 16MB of them queue up on the buffer,
the Tor process will close the socket.
```
This happened in #16480 or maybe some time before it.Tor: 0.3.1.x-final