Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:11:48Zhttps://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/22916Clang warnings when building with openssl and scrypt2020-06-13T15:11:42ZNick MathewsonClang warnings when building with openssl and scrypt```
src/test/test_crypto_slow.c:161:23: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk...```
src/test/test_crypto_slow.c:161:23: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:161:26: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:181:23: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:181:26: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:204:23: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:204:26: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:228:23: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
^
src/test/test_crypto_slow.c:228:26: error: implicit conversion loses integer
precision: 'uint64_t' (aka 'unsigned long') to 'uint32_t'
(aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
N, r, p, buf1, dk_len);
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22824Establish guidelines for using assertions2020-06-13T15:11:17ZTaylor YuEstablish guidelines for using assertionsBugs like #22789 can happen due to overuse of assertions. We should have guidelines for when assertions are appropriate, and document them (probably in `CodingStyle.md`).Bugs like #22789 can happen due to overuse of assertions. We should have guidelines for when assertions are appropriate, and document them (probably in `CodingStyle.md`).Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22803Memory leak in link-handshake/certs_ok_ed255192020-06-13T15:11:11ZNick MathewsonMemory leak in link-handshake/certs_ok_ed25519=================================================================
==24816==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e6...=================================================================
==24816==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x5582ccbf96ea in tor_malloc_ src/common/util.c:150
#2 0x5582ccbf9791 in tor_malloc_zero_ src/common/util.c:178
#3 0x5582ccb7d8ae in tor_x509_cert_new__real src/common/tortls.c:677
#4 0x5582cc61f504 in test_link_handshake_certs_ok src/test/test_link_handshake.c:232
#5 0x5582cc783a78 in testcase_run_bare_ src/ext/tinytest.c:106
#6 0x5582cc783f76 in testcase_run_forked_ src/ext/tinytest.c:190
#7 0x5582cc783f76 in testcase_run_one src/ext/tinytest.c:248
#8 0x5582cc785465 in tinytest_main src/ext/tinytest.c:435
#9 0x5582cc3d7846 in main src/test/testing_common.c:319
#10 0x7fe71e6c4400 in __libc_start_main (/lib64/libc.so.6+0x20400)
Indirect leak of 3050 byte(s) in 58 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x7fe7204e03e7 in CRYPTO_malloc (/lib64/libcrypto.so.10+0x6e3e7)
Indirect leak of 579 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x5582ccbf96ea in tor_malloc_ src/common/util.c:150
#2 0x5582ccb7d904 in tor_x509_cert_new__real src/common/tortls.c:687
#3 0x5582cc61f504 in test_link_handshake_certs_ok src/test/test_link_handshake.c:232
#4 0x5582cc783a78 in testcase_run_bare_ src/ext/tinytest.c:106
#5 0x5582cc783f76 in testcase_run_forked_ src/ext/tinytest.c:190
#6 0x5582cc783f76 in testcase_run_one src/ext/tinytest.c:248
#7 0x5582cc785465 in tinytest_main src/ext/tinytest.c:435
#8 0x5582cc3d7846 in main src/test/testing_common.c:319
#9 0x7fe71e6c4400 in __libc_start_main (/lib64/libc.so.6+0x20400)Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22731Relative DataDirectory + RunAsDaemon = Tor can't read or write most of its da...2020-06-13T15:33:41ZRoger DingledineRelative DataDirectory + RunAsDaemon = Tor can't read or write most of its datadirectory filesBug #22101 shows a case where if you start your Tor with a relative (non absolute) DataDirectory, and `RunAsDaemon 1`, and `CookieAuthentication 1` but no `CookieAuthFile`, then Tor will attempt to save your control_auth_cookie file to $...Bug #22101 shows a case where if you start your Tor with a relative (non absolute) DataDirectory, and `RunAsDaemon 1`, and `CookieAuthentication 1` but no `CookieAuthFile`, then Tor will attempt to save your control_auth_cookie file to $datadir/$datadir/control_auth_cookie. (Yes, you read that correctly, $datadir/$datadir/.) The attempt will fail because Tor doesn't mkdir the $datadir/$datadir directory.
If you start with a relative DataDirectory, and RunAsDaemon, but no CookieAuthentication, then your Tor will start, but it will attempt to (and fail to) write each of your datadirectory files -- state, cached-microdescriptors, etc, because it is trying to write them to $datadir/$datadir. I think that might be what teor saw in #20456, but he doesn't give us an actual torrc so I can't be sure.
The bug is because we call get_datadir_fname(), which creates a filename that prepends $datadir, after we do the chdir($datadir) operation that comes with RunAsDaemon.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22684Expose we_fetch_{micro,router_}descriptors on control port2020-06-13T15:10:24ZNick MathewsonExpose we_fetch_{micro,router_}descriptors on control portRight now, stem has some slightly wrong logic:
https://gitweb.torproject.org/stem.git/tree/stem/control.py#n1828
We should make GETINFO commands to fetch these. How about
```
info/config/we-download-microdescs and
info/config/we-down...Right now, stem has some slightly wrong logic:
https://gitweb.torproject.org/stem.git/tree/stem/control.py#n1828
We should make GETINFO commands to fetch these. How about
```
info/config/we-download-microdescs and
info/config/we-download-routerdescs
```
?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22672Defensive programming: ensure no infinite COMPRESS_OK loops2020-06-13T15:10:23ZNick MathewsonDefensive programming: ensure no infinite COMPRESS_OK loopsThere's a possible failure mode if we've screwed up in our compression backends: we might say "COMPRESS_OK" over and over, while not making any progress. The changes I'm suggesting in #22629 turn this possible bug into a possible infini...There's a possible failure mode if we've screwed up in our compression backends: we might say "COMPRESS_OK" over and over, while not making any progress. The changes I'm suggesting in #22629 turn this possible bug into a possible infinite loop.
I don't think this failure mode actually exists today, but let's prevent it anyway, by treating a COMPRESS_OK that makes no progress as if it were an error, and a BUG.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22644Assert crash with HSPOST and POSTDESCRIPTOR control port commands2020-06-13T15:10:17ZdonnchaAssert crash with HSPOST and POSTDESCRIPTOR control port commandsThe HSPOST and POSTDESCRIPTOR control port command accept multi-line data. Both of these commands crash when they receive an empty command body.
A trivial test case is as follows:
```
AUTHENTICATE
+HSPOST
.
```
Stacktraces:
```
Jun 18...The HSPOST and POSTDESCRIPTOR control port command accept multi-line data. Both of these commands crash when they receive an empty command body.
A trivial test case is as follows:
```
AUTHENTICATE
+HSPOST
.
```
Stacktraces:
```
Jun 18 19:27:41.000 [err] tor_assertion_failed_(): Bug: ../src/or/control.c:3098: handle_control_postdescriptor: Assertion cp failed; aborting. (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: Assertion cp failed in handle_control_postdescriptor at ../src/or/control.c:3098. Stack trace: (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(log_backtrace+0x42) [0x564171496242] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(tor_assertion_failed_+0x94) [0x5641714a44f4] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(connection_control_process_inbuf+0x279a) [0x5641714602da] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0xe81c5) [0x56417144a1c5] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0x410f1) [0x5641713a30f1] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fe33b428420] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(do_main_loop+0x21d) [0x5641713a40bd] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(tor_main+0x1b95) [0x5641713a7675] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(main+0x19) [0x56417139fdc9] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fe33a5643f1] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0x3de1b) [0x56417139fe1b] (on Tor 0.2.8.9 )
[1] 14542 abort tor -f torrc.local
```
```
Jun 18 19:35:43.000 [err] tor_assertion_failed_(): Bug: ../src/common/util.c:316: tor_strndup_: Assertion n < SIZE_T_CEILING failed; aborting. (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: Assertion n < SIZE_T_CEILING failed in tor_strndup_ at ../src/common/util.c:316. Stack trace: (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(log_backtrace+0x42) [0x564aa98a8242] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_assertion_failed_+0x94) [0x564aa98b64f4] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_strndup_+0x91) [0x564aa98b6e01] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x3bef8) [0x564aa97afef8] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(connection_control_process_inbuf+0x1e1f) [0x564aa987195f] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0xe81c5) [0x564aa985c1c5] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x410f1) [0x564aa97b50f1] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f1ea6c60420] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(do_main_loop+0x21d) [0x564aa97b60bd] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_main+0x1b95) [0x564aa97b9675] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(main+0x19) [0x564aa97b1dc9] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f1ea5d9c3f1] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x3de1b) [0x564aa97b1e1b] (on Tor 0.2.8.9 )
[1] 15378 abort tor -f torrc.local
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22516tor fails to start with 'Sandbox 1'2020-06-13T15:10:03Zcypherpunkstor fails to start with 'Sandbox 1'OS: CentOS 7
SELinux: disabled
tor-0.2.9.10-1.el7.x86_64
```
============================================================
(Sandbox) Caught a bad syscall attempt (syscall fchmod)
/usr/bin/tor(+0x15d83a)[0x7ff9aa58b83a]
/lib64/libc.s...OS: CentOS 7
SELinux: disabled
tor-0.2.9.10-1.el7.x86_64
```
============================================================
(Sandbox) Caught a bad syscall attempt (syscall fchmod)
/usr/bin/tor(+0x15d83a)[0x7ff9aa58b83a]
/lib64/libc.so.6(fchmod+0x7)[0x7ff9a8b1a917]
/lib64/libc.so.6(fchmod+0x7)[0x7ff9a8b1a917]
/usr/bin/tor(check_private_dir+0x151)[0x7ff9aa584741]
/usr/bin/tor(init_keys+0x9b)[0x7ff9aa4b6cab]
/usr/bin/tor(do_main_loop+0x4b)[0x7ff9aa472b1b]
/usr/bin/tor(tor_main+0x1c25)[0x7ff9aa4763a5]
/usr/bin/tor(main+0x19)[0x7ff9aa46e8c9]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff9a8a53b35]
/usr/bin/tor(+0x4091b)[0x7ff9aa46e91b]
```
torrc:
```
OfflineMasterKey 1
RunAsDaemon 0
Log notice syslog
OutboundBindAddress ...
SocksPort 0
User ...
DataDirectory /var/lib/tor-instances/...
ORPort ...
DirPort ...
SyslogIdentityTag ...
Nickname ...
ControlSocket 0
CookieAuthentication 0
ExitRelay 0
ExitPolicy reject *:*
Sandbox 1
ShutdownWaitLength 1
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22284Make a proper wiki page for trove severity guidelines2020-06-13T15:09:08ZRoger DingledineMake a proper wiki page for trove severity guidelinesThere are these two pages:
https://trac.torproject.org/projects/tor/wiki/TROVE
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy
But that second one isn't really a great long term ...There are these two pages:
https://trac.torproject.org/projects/tor/wiki/TROVE
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy
But that second one isn't really a great long term resource for people wondering what the trove is, or what should count as a thing that should be in the trove. It would be nice to have a page that looks like it's actually an in-place policy.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22281Prevent pattern of bugs caused by calling get_options() within options_valida...2020-06-13T15:09:07ZNick MathewsonPrevent pattern of bugs caused by calling get_options() within options_validate() etcIn #22252 and elsewhere, we hit a problem with calling a function that called get_options() -- both directly and via networkstatus_get_latest_consensus() -- before the options were fully assigned.
We ought to do something to eliminate t...In #22252 and elsewhere, we hit a problem with calling a function that called get_options() -- both directly and via networkstatus_get_latest_consensus() -- before the options were fully assigned.
We ought to do something to eliminate this pattern of bugs.
One possibility might be to 'fill in' the new options before they're completely validated. But we'd want to be able to roll back to the old options as needed if the new options _didn't_ validate.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22128Refactor body of connection_dir_client_reached_eof()2020-06-13T15:08:25ZNick MathewsonRefactor body of connection_dir_client_reached_eof()What's this 630-line function doing in our codebase?What's this 630-line function doing in our codebase?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22065prop278: Parse the Accept-Encoding header and pass it to "get" handlers2020-06-13T15:08:12ZNick Mathewsonprop278: Parse the Accept-Encoding header and pass it to "get" handlersI need this for my prop140 work.I need this for my prop140 work.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22061prop140/prop278: use atomic counters to track memory usage2020-06-13T15:08:11ZNick Mathewsonprop140/prop278: use atomic counters to track memory usageI want to be able to compress things in subthreads, but that means that using plain old statics for our allocation counters won't work.I want to be able to compress things in subthreads, but that means that using plain old statics for our allocation counters won't work.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21943(Sandbox) Caught a bad syscall attempt (syscall getpid)2020-06-13T15:07:48ZTrac(Sandbox) Caught a bad syscall attempt (syscall getpid)Tor version: 0.2.9.10-1
Debian sid 4.9.0-2-amd64
```
(Sandbox) Caught a bad syscall attempt (syscall getpid)
/usr/bin/tor(+0x16146a)[0x560e7566046a]
/lib/x86_64-linux-gnu/libc.so.6(getpid+0x7)[0x7fab93288d87]
/lib/x86_64-linux-gnu/libc...Tor version: 0.2.9.10-1
Debian sid 4.9.0-2-amd64
```
(Sandbox) Caught a bad syscall attempt (syscall getpid)
/usr/bin/tor(+0x16146a)[0x560e7566046a]
/lib/x86_64-linux-gnu/libc.so.6(getpid+0x7)[0x7fab93288d87]
/lib/x86_64-linux-gnu/libc.so.6(getpid+0x7)[0x7fab93288d87]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x18ca17)[0x7fab93d60a17]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0xc7471)[0x7fab93c9b471]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(BN_generate_prime_ex+0x4f7)[0x7fab93c9a577]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(RSA_generate_key_ex+0x177)[0x7fab93d67e97]
/usr/bin/tor(crypto_pk_generate_key_with_bits+0xb5)[0x560e75666e15]
/usr/bin/tor(init_keys_client+0x39)[0x560e75582ef9]
/usr/bin/tor(init_keys+0x3c)[0x560e7558738c]
/usr/bin/tor(do_main_loop+0x4f)[0x560e7554267f]
/usr/bin/tor(tor_main+0x1c25)[0x560e75546295]
/usr/bin/tor(main+0x19)[0x560e7553e2a9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fab931f02b1]
/usr/bin/tor(_start+0x2a)[0x560e7553e2fa]
```
**Trac**:
**Username**: ageisp0lisTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21894Base32_encode: *actually* allow inputs of odd sizes2020-06-13T15:07:41ZNick MathewsonBase32_encode: *actually* allow inputs of odd sizesWhen we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equal to 0 or 3...When we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equal to 0 or 3.
This is not _completely_ horrible, for two reasons:
* The extra bits that are read are never actually used: so this is only a crash when asan is enabled, in the worst case.
* The input sizes passed to base32_encode are only ever multiples of 5. They are all either DIGEST_LEN (20), REND_SERVICE_ID_LEN (10), sizeof(rand_bytes) in addressmap.c (10), or an input in crypto.c that is forced to a multiple of 5. So this bug can't actually trigger.
Nonetheless, let's fix it!Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21737Speed up keccak-tiny: Use a real load64 function2020-06-13T15:07:18ZNick MathewsonSpeed up keccak-tiny: Use a real load64 functionThe current load-le64 function shows up in keccak profiles. Of course, that's silly. We can do better -- and we do, in other crypto primitives.The current load-le64 function shows up in keccak profiles. Of course, that's silly. We can do better -- and we do, in other crypto primitives.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21472doc/HACKING/FUZZING.md uses outdated make target fuzz2020-06-13T15:06:21Zteordoc/HACKING/FUZZING.md uses outdated make target fuzzI guess this should be the corpora target from #21447?
```
AFL_HARDEN=1 make clean fuzz
```I guess this should be the corpora target from #21447?
```
AFL_HARDEN=1 make clean fuzz
```Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21037Scary log message "AAAA...AAA" in connection_or_set_identity_digest()2020-06-13T15:04:45ZRoger DingledineScary log message "AAAA...AAA" in connection_or_set_identity_digest()On moria1 running today's 0.3.0.1-alpha-dev, I see these info-level logs:
```
Dec 19 20:42:39.727 [info] connection_or_set_identity_digest(): Set identity digest for 0x1369a250 ((null)): FFD94A523D3A66323E3E4F7707AFCBD44A8D38C4 <null>.
D...On moria1 running today's 0.3.0.1-alpha-dev, I see these info-level logs:
```
Dec 19 20:42:39.727 [info] connection_or_set_identity_digest(): Set identity digest for 0x1369a250 ((null)): FFD94A523D3A66323E3E4F7707AFCBD44A8D38C4 <null>.
Dec 19 20:42:39.727 [info] connection_or_set_identity_digest(): (Previously: 0000000000000000000000000000000000000000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
```
That last part reminds me of elsewhere in our code where we do
```
memwipe(mem, 0xAA, memlen); /* poison memory */
```
Coincidence? I think it is, because I bet AAA..AAA is the base64 of 000..000, since I see ed25519_fmt() returns a base64 thing.
Still, I wonder if we might do a smarter log message for the case where the key used to be unset, since I'm not the only person who is going to see this line and be concerned.Tor: 0.3.0.x-final