Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:52:09Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27734tor on OpenSSL claims not to support LinkAuth=12020-06-27T13:52:09Zteortor on OpenSSL claims not to support LinkAuth=1HAVE_WORKING_TOR_TLS_GET_TLSSECRETS is defined in tortls.h, which protover.c and test_protover.c do not include.
Therefore, every Tor on master now thinks it only supports LinkAuth=3:
```
#ifdef HAVE_WORKING_TOR_TLS_GET_TLSSECRETS
"...HAVE_WORKING_TOR_TLS_GET_TLSSECRETS is defined in tortls.h, which protover.c and test_protover.c do not include.
Therefore, every Tor on master now thinks it only supports LinkAuth=3:
```
#ifdef HAVE_WORKING_TOR_TLS_GET_TLSSECRETS
"LinkAuth=1,3 "
#else
"LinkAuth=3 "
#endif
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27730CID 1439330: "st.st_size > 9223372036854775807L" is always false2020-06-27T13:52:09ZteorCID 1439330: "st.st_size > 9223372036854775807L" is always falseCoverity claims:
```
*** CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/src/lib/crypt_ops/crypto_rsa.c: 554 in crypto_pk_read_private_key_from_filename()
548 const char *...Coverity claims:
```
*** CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/src/lib/crypt_ops/crypto_rsa.c: 554 in crypto_pk_read_private_key_from_filename()
548 const char *keyfile)
549 {
550 struct stat st;
551 char *buf = read_file_to_str(keyfile, 0, &st);
552 if (!buf)
553 return -1;
CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
"st.st_size > 9223372036854775807L" is always false regardless of the values of its operands. This occurs as the logical operand of "if".
554 if (st.st_size > SSIZE_MAX)
555 return -1;
556
557 int rv = crypto_pk_read_private_key_from_string(env, buf,
558 (ssize_t)st.st_size);
559 memwipe(buf, 0, (size_t)st.st_size);
```
But st_size is off_t, and the POSIX standard doesn't require a particular size for off_t:
```
blkcnt_t and off_t shall be signed integer types.
```
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67
In particular, some 32-bit pointer (SSIZE_MAX) operating systems may have a 64-bit file off_t. (I know that at least one BSD does, and I suspect that macOS and Linux also do in their 64-bit file size modes.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27728Signature mismatch for crypto_strongest_rand() in ed-donna code breaks -flto ...2020-06-27T13:52:10ZAlex XuSignature mismatch for crypto_strongest_rand() in ed-donna code breaks -flto compilation```
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
MOCK_DECL(void,crypto_strongest_rand,(uint8_t *out, size_t out_len));
^
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ...```
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
MOCK_DECL(void,crypto_strongest_rand,(uint8_t *out, size_t out_len));
^
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
src/lib/crypt_ops/crypto_rand.c:338:1: note: previously declared here
MOCK_IMPL(void,
^
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27711Hardened build fails in tortls_openssl.c2020-06-27T13:52:10Zrl1987Hardened build fails in tortls_openssl.c```
src/lib/tls/tortls_openssl.c: In function ‘tor_tls_release_socket’:
src/lib/tls/tortls_openssl.c:1172:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(rbio, BIO_NOCLOSE);
^
src/lib/tls/tortls_openss...```
src/lib/tls/tortls_openssl.c: In function ‘tor_tls_release_socket’:
src/lib/tls/tortls_openssl.c:1172:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(rbio, BIO_NOCLOSE);
^
src/lib/tls/tortls_openssl.c:1175:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(wbio, BIO_NOCLOSE);
^
cc1: all warnings being treated as errors
make: *** [src/lib/tls/src_lib_libtor_tls_a-tortls_openssl.o] Error 1
```
https://travis-ci.org/torproject/tor/jobs/428655734Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27709The compiler doesn't warn about tor_assert(a = b)2020-06-27T13:52:10ZNick MathewsonThe compiler doesn't warn about tor_assert(a = b)C's assignment expressions are notoriously easy to mis-type when you are trying to enter an equality expression instead. Most compilers will notice when you say something like `if (a = b)`, and make you add an extra set of parentheses. ...C's assignment expressions are notoriously easy to mis-type when you are trying to enter an equality expression instead. Most compilers will notice when you say something like `if (a = b)`, and make you add an extra set of parentheses. But we've done something with our tor_assert() macro so this doesn't happen. We should fix that.
Found from ahf's review of legacy/trac#27289
We should also make sure BUG doesn't have this problem.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27687rust protover accepts non ASCII in protocol names2020-06-27T13:52:11ZTracrust protover accepts non ASCII in protocol names
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27685Memory leak in tortls/openssl/context_new2020-06-27T13:52:11ZNick MathewsonMemory leak in tortls/openssl/context_newNot sure how far to backport this one; let's see.Not sure how far to backport this one; let's see.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27684Memory leak in tortls/openssl/try_to_extract_certs_from_tls2020-06-27T13:52:11ZNick MathewsonMemory leak in tortls/openssl/try_to_extract_certs_from_tlsThere's a memory leak reported on the unit test `tortls/openssl/try_to_extract_certs_from_tls`. Not sure how far to backport; let's see.There's a memory leak reported on the unit test `tortls/openssl/try_to_extract_certs_from_tls`. Not sure how far to backport; let's see.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27678Emit CIRC_BW event early for dropped cells2020-06-27T13:52:12ZMike PerryEmit CIRC_BW event early for dropped cellsWhile reviewing the dropmark paper (https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf) and asking the authors to test it against vanguards's dropped cell detection, I realized that since we only normally emit CIRC_BW...While reviewing the dropmark paper (https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf) and asking the authors to test it against vanguards's dropped cell detection, I realized that since we only normally emit CIRC_BW events once per second, the attack may still have enough time succeed against vanguards.
The fix is to emit the CIRC_BW event as soon as we get a relay cell that does not cause us to update our delivered or overhead byte counts. It's pretty simply to do this. Patch incoming.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27675test_rebind.py depends on python >=2.7 or >=3.12020-06-27T13:52:12ZTaylor Yutest_rebind.py depends on python >=2.7 or >=3.1It looks like test_rebind.py added as part of legacy/trac#17873 doesn't work for me ~~on macOS 10.12.6, which has~~ with python 2.6. test_rebind.py uses `str.format()` without a field name or number, which is new in python 2.7 or 3.1. ...It looks like test_rebind.py added as part of legacy/trac#17873 doesn't work for me ~~on macOS 10.12.6, which has~~ with python 2.6. test_rebind.py uses `str.format()` without a field name or number, which is new in python 2.7 or 3.1. It also tries to run with python3 (for unknown reasons), but ends up not necessarily doing so because test_rebind.sh explicitly runs `$PYTHON` or `python`.
Replacing instances of `{}` in format strings with `{0}` seems to work.
What is our minimum required python version anyway?Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/27670Memleak on tor master 95fcad4088eba52e2020-06-27T13:52:12ZDavid Gouletdgoulet@torproject.orgMemleak on tor master 95fcad4088eba52eOn latest master, normal client starts with a Ctrl+C. Notice the "Listener on ???:0" which seems to me the end of a list we fail to recognize? And then the memleak.
```
Sep 12 15:21:48.615 [notice] Tor 0.3.5.0-alpha-dev (git-95fcad4088e...On latest master, normal client starts with a Ctrl+C. Notice the "Listener on ???:0" which seems to me the end of a list we fail to recognize? And then the memleak.
```
Sep 12 15:21:48.615 [notice] Tor 0.3.5.0-alpha-dev (git-95fcad4088eba52e) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0h, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd N/A.
Sep 12 15:21:48.615 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 12 15:21:48.615 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 12 15:21:48.615 [notice] Read configuration file "/home/dgoulet/temp/tor/torrc".
Sep 12 15:21:48.618 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
Sep 12 15:21:48.619 [notice] Opening Socks listener on 127.0.0.1:9250
Sep 12 15:21:48.620 [notice] Opened Socks listener on 127.0.0.1:9250
Sep 12 15:21:48.620 [notice] Opening Socks listener on /home/dgoulet/temp/tor/client/socks.sock
Sep 12 15:21:48.620 [notice] Opened Socks listener on ???:0
Sep 12 15:21:48.620 [notice] Opening Control listener on 127.0.0.1:9051
Sep 12 15:21:48.620 [notice] Opened Control listener on 127.0.0.1:9051
Sep 12 15:21:48.620 [notice] Opening Control listener on /home/dgoulet/temp/tor/client/control.sock
Sep 12 15:21:48.620 [notice] Opened Control listener on ???:0
^C
=================================================================
==22622==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7fd64617ef30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x555bb37c2caa in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x555bb37be8e5 in smartlist_new src/lib/smartlist_core/smartlist_core.c:28
#3 0x555bb3689c2d in retry_all_listeners src/core/mainloop/connection.c:2831
#4 0x555bb312bcbd in retry_listeners_callback src/core/mainloop/main.c:2342
#5 0x555bb31427fe in periodic_event_dispatch src/core/mainloop/periodic.c:56
#6 0x7fd645ab4a10 (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6+0x1ea10)
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7fd64617ef30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x555bb37c2caa in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x555bb37be8e5 in smartlist_new src/lib/smartlist_core/smartlist_core.c:28
#3 0x555bb3689c2d in retry_all_listeners src/core/mainloop/connection.c:2831
#4 0x555bb363108b in options_act_reversible src/app/config/config.c:1493
#5 0x555bb363108b in set_options src/app/config/config.c:903
#6 0x555bb363b827 in options_init_from_string src/app/config/config.c:5466
#7 0x555bb363ce10 in options_init_from_torrc src/app/config/config.c:5230
#8 0x555bb31401d8 in tor_init src/core/mainloop/main.c:3540
#9 0x555bb3141b00 in tor_run_main src/core/mainloop/main.c:4275
#10 0x555bb312b9ab in tor_main src/feature/api/tor_api.c:164
#11 0x555bb31268bb in main src/app/main/tor_main.c:32
#12 0x7fd64443309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7fd64617ef30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x555bb37c2caa in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x555bb37c2d41 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x555bb37be999 in smartlist_new src/lib/smartlist_core/smartlist_core.c:31
#4 0x555bb3689c2d in retry_all_listeners src/core/mainloop/connection.c:2831
#5 0x555bb312bcbd in retry_listeners_callback src/core/mainloop/main.c:2342
#6 0x555bb31427fe in periodic_event_dispatch src/core/mainloop/periodic.c:56
#7 0x7fd645ab4a10 (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6+0x1ea10)
Indirect leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7fd64617ef30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x555bb37c2caa in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x555bb37c2d41 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x555bb37be999 in smartlist_new src/lib/smartlist_core/smartlist_core.c:31
#4 0x555bb3689c2d in retry_all_listeners src/core/mainloop/connection.c:2831
#5 0x555bb363108b in options_act_reversible src/app/config/config.c:1493
#6 0x555bb363108b in set_options src/app/config/config.c:903
#7 0x555bb363b827 in options_init_from_string src/app/config/config.c:5466
#8 0x555bb363ce10 in options_init_from_torrc src/app/config/config.c:5230
#9 0x555bb31401d8 in tor_init src/core/mainloop/main.c:3540
#10 0x555bb3141b00 in tor_run_main src/core/mainloop/main.c:4275
#11 0x555bb312b9ab in tor_main src/feature/api/tor_api.c:164
#12 0x555bb31268bb in main src/app/main/tor_main.c:32
#13 0x7fd64443309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
SUMMARY: AddressSanitizer: 288 byte(s) leaked in 4 allocation(s).
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27664Initialization error when using NSS with Chutney2020-06-27T13:52:12ZNick MathewsonInitialization error when using NSS with ChutneyI see a bunch bugs with 'make test-network' when nss is turned on. Better fix them.
One example:
```
Sep 12 11:35:38.273 [warn] NSS error SEC_ERROR_PKCS11_DEVICE_ERROR while decoding an RSA private key: A PKCS #11 module returned CKR_D...I see a bunch bugs with 'make test-network' when nss is turned on. Better fix them.
One example:
```
Sep 12 11:35:38.273 [warn] NSS error SEC_ERROR_PKCS11_DEVICE_ERROR while decoding an RSA private key: A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot.
Sep 12 11:35:38.273 [err] Error loading private key.
Sep 12 11:35:38.273 [warn] No version 3 directory key found in /home/nickm/src/chutney/net/nodes/000a/keys/authority_signing_key
Sep 12 11:35:38.273 [err] We're configured as a V3 authority, but we were unable to load our v3 authority keys and certificate! Use tor-gencert to generate them. Dying.
Sep 12 11:35:38.273 [warn] options_act(): Bug: Error initializing keys; exiting (on Tor 0.3.5.0-alpha-dev bfc847255afb093b)
Sep 12 11:35:38.273 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.5.0-alpha-dev bfc847255afb093b)
```
Another:
```
Sep 12 11:35:38.415 [err] tor_assertion_failed_(): Bug: ../src/lib/crypt_ops/cry
pto_rand.c:500: crypto_rand_unmocked: Assertion PR_GetError() == SEC_ERROR_INVAL
ID_ARGS && n > BUFLEN failed; aborting. (on Tor 0.3.5.0-alpha-dev bfc847255afb09
3b)
Sep 12 11:35:38.416 [err] Bug: Assertion PR_GetError() == SEC_ERROR_INVALID_ARGS
&& n > BUFLEN failed in crypto_rand_unmocked at ../src/lib/crypt_ops/crypto_ran
d.c:500. Stack trace: (on Tor 0.3.5.0-alpha-dev bfc847255afb093b)
Sep 12 11:35:38.416 [err] Bug: /home/nickm/src/tor-nss/build_nss/src/app/tor
(log_backtrace_impl+0x46) [0x55b4a1f40d16] (on Tor 0.3.5.0-alpha-dev bfc847255af
b093b)
Sep 12 11:35:38.416 [err] Bug: /home/nickm/src/tor-nss/build_nss/src/app/tor
(tor_assertion_failed_+0x94) [0x55b4a1f3c324] (on Tor 0.3.5.0-alpha-dev bfc84725
5afb093b)
Sep 12 11:35:38.416 [err] Bug: /home/nickm/src/tor-nss/build_nss/src/app/tor
(+0x1985a7) [0x55b4a1ef15a7] (on Tor 0.3.5.0-alpha-dev bfc847255afb093b)
Sep 12 11:35:38.416 [err] Bug: /home/nickm/src/tor-nss/build_nss/src/app/tor
(init_cookie_authentication+0x92) [0x55b4a1ec68b2] (on Tor 0.3.5.0-alpha-dev bfc
847255afb093b)
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27658Nonzero exit from forked testcase should make the testcase fail2020-06-27T13:52:13ZNick MathewsonNonzero exit from forked testcase should make the testcase failIn our unit tests, if a forked testcase crashes after having reported success (as can happen on a memory leak under lsan), the parent won't learn about it right now. That's obviously not great. Let's fix it.In our unit tests, if a forked testcase crashes after having reported success (as can happen on a memory leak under lsan), the parent won't learn about it right now. That's obviously not great. Let's fix it.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27649rust protover double-counts protocol versions2020-06-27T13:52:13ZTracrust protover double-counts protocol versionsOr triple-, or N-counts. `"Bar=1,1,1,1,1,1,1"` gets parsed as 7 votes.
It fails the unit test from legacy/trac#27205.
**Trac**:
**Username**: cyberpunksOr triple-, or N-counts. `"Bar=1,1,1,1,1,1,1"` gets parsed as 7 votes.
It fails the unit test from legacy/trac#27205.
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27644wrong documentation of networkstatus_read_cached_consensus_impl2020-06-27T13:52:14ZTracwrong documentation of networkstatus_read_cached_consensus_implIt says false when it meant to say 'true.'
**Trac**:
**Username**: cyberpunksIt says false when it meant to say 'true.'
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27630use strcmpstart() in rend_parse_v2_service_descriptor2020-06-27T13:52:14ZTracuse strcmpstart() in rend_parse_v2_service_descriptor
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27618LLVM scan-build: src/tools/tor-resolve.c:224:3: warning: Value stored to 'soc...2020-06-27T13:52:14Zrl1987LLVM scan-build: src/tools/tor-resolve.c:224:3: warning: Value stored to 'socklen' is never read```
src/tools/tor-resolve.c:224:3: warning: Value stored to 'socklen' is never read
socklen = tor_addr_to_sockaddr(sockshost, socksport,
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
``````
src/tools/tor-resolve.c:224:3: warning: Value stored to 'socklen' is never read
socklen = tor_addr_to_sockaddr(sockshost, socksport,
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27606Handle coverity issues related to recently merged HS client auth2020-06-27T13:52:15ZGeorge KadianakisHandle coverity issues related to recently merged HS client authTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27547hs-v3: Client authorization feature needs a changes file and man page2020-06-27T13:52:16ZDavid Gouletdgoulet@torproject.orghs-v3: Client authorization feature needs a changes file and man pageTo remind ourselves that we can't release 035 without the changes file and man page entry for the v3 client authorization.To remind ourselves that we can't release 035 without the changes file and man page entry for the v3 client authorization.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27545hs-v3: Shuffle the client authorization ordering in the descriptor2020-06-27T13:52:16ZDavid Gouletdgoulet@torproject.orghs-v3: Shuffle the client authorization ordering in the descriptorIt would be desirable to shuffle the list of clients in a descriptor (if any) so no one can learn anything from the ordering.
haxxpop has already done code for this:
https://github.com/haxxpop/tor/commit/3ac776bd988
This can go post 03...It would be desirable to shuffle the list of clients in a descriptor (if any) so no one can learn anything from the ordering.
haxxpop has already done code for this:
https://github.com/haxxpop/tor/commit/3ac776bd988
This can go post 035 freeze.Tor: 0.3.5.x-final