Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:13:03Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3940Allow MapAddress .exit even if AllowDotExit is 02020-06-13T14:13:03ZSteven MurdochAllow MapAddress .exit even if AllowDotExit is 0If AllowDotExit is 0 (the default) MapAddress doesn't permit a .exit address to be set as the destination. It is desirable to keep AllowDotExit disabled for security reasons, but there shouldn't be any harm in always permitting MapAddres...If AllowDotExit is 0 (the default) MapAddress doesn't permit a .exit address to be set as the destination. It is desirable to keep AllowDotExit disabled for security reasons, but there shouldn't be any harm in always permitting MapAddress entries because the user must enter these manually. This feature is desirable because it allows the user to force exit enclaving.
Using Tor v0.2.2.32 (git-877e17749725ab88).Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6767tor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd failed2020-06-13T14:28:12ZLeonid Evdokimovtor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd failedI started my gateway with stderr redirected to syslog and got following crash:
```
Sep 2 12:30:07 OpenWrt cron.info crond[708]: crond: USER root pid 1794 cmd /root/tor-watchdog.sh
Sep 2 12:43:19 OpenWrt daemon.err Tor[1280]: routerlist...I started my gateway with stderr redirected to syslog and got following crash:
```
Sep 2 12:30:07 OpenWrt cron.info crond[708]: crond: USER root pid 1794 cmd /root/tor-watchdog.sh
Sep 2 12:43:19 OpenWrt daemon.err Tor[1280]: routerlist_remove_old(): Bug: routerlist.c:3004: routerlist_remove_old: Assertion idx == sd->routerlist_index failed; aborting.
Sep 2 12:43:21 OpenWrt user.notice tor.stdout: routerlist.c:3004 routerlist_remove_old: Assertion idx == sd->routerlist_index failed; aborting.
Sep 2 12:45:01 OpenWrt cron.info crond[708]: crond: USER root pid 1797 cmd /root/tor-watchdog.sh
Sep 2 12:45:01 OpenWrt user.notice Tor.watchdog: pidfile exists and process is missing - start
Sep 2 12:45:02 OpenWrt user.notice Tor.init: Sep 02 12:45:02.684 [notice] Tor v0.2.2.37 (git-fce6eb1c44e87bc2). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux mips)
```
OpenWrt package versions: libopenssl - 1.0.1c-1, tor - 0.2.2.37-1
openssl build information:
```
root@OpenWrt:~# strings /usr/lib/libcrypto.so.1.0.0 | grep gcc
libgcc_s.so.1
mipsel-openwrt-linux-uclibc-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -I/home/fnord/slave/brcm47xx/build/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/include -I/home/fnord/slave/brcm47xx/build/staging_dir/target-mipsel_uClibc-0.9.33.2/include -I/home/fnord/slave/brcm47xx/build/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/usr/include -I/home/fnord/slave/brcm47xx/build/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/include -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -DTERMIO -Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -fpic -DOPENSSL_THREADS -pthread -D_REENTRANT -D_THREAD_SAFE -D_THREADSAFE -fomit-frame-pointer -Wall
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15582compile warning in test_util.c: In function 'test_util_sscanf'2020-06-13T14:45:01ZTraccompile warning in test_util.c: In function 'test_util_sscanf'Environment:
OpenBSD 5.6 release with Libevent 1.4.14b-stable, OpenSSL LibreSSL 2.1.6 and Zlib 1.2.3
------------------
CC src/test/src_test_test-test_util.o
src/test/test_util.c: In function 'test_util_sscanf':
src/test/test_ut...Environment:
OpenBSD 5.6 release with Libevent 1.4.14b-stable, OpenSSL LibreSSL 2.1.6 and Zlib 1.2.3
------------------
CC src/test/src_test_test-test_util.o
src/test/test_util.c: In function 'test_util_sscanf':
src/test/test_util.c:1843: warning: Array size (20) smaller than format string size (1000000) (arg 3)
src/test/test_util.c:1949: warning: Array size (20) smaller than format string size (1000) (arg 3)
CC src/test/src_test_test-test_helpers.o
-----------------
**Trac**:
**Username**: sysfuTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19760Update longclaw's hard-coded IPv6 address2020-06-13T14:59:45ZteorUpdate longclaw's hard-coded IPv6 addressIn 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
...In 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145
Should we update this before the 0.2.8 release?Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21074setrlimit fails OSX Sierra2020-06-13T15:04:57Zcypherpunkssetrlimit fails OSX SierraUser reported on Tor Stack Exchange that Tor Browser under their Sierra install was failing.
It seems to be caused by a failed call to "setrlimit"
```
Dec 21 23:52:00.089 [notice] Tor 0.2.9.6-rc (git-a3e07633a45d5c16) running on Darwin...User reported on Tor Stack Exchange that Tor Browser under their Sierra install was failing.
It seems to be caused by a failed call to "setrlimit"
```
Dec 21 23:52:00.089 [notice] Tor 0.2.9.6-rc (git-a3e07633a45d5c16) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 21 23:52:00.090 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 21 23:52:00.091 [notice] Read configuration file "/Applications/TorBrowser.app/Contents/Resources/TorBrowser/Tor/torrc-defaults".
Dec 21 23:52:00.092 [notice] Read configuration file "/Users/leomozoloa/Library/Application Support/TorBrowser-Data/Tor/torrc".
Dec 21 23:52:00.106 [warn] Couldn't set maximum number of file descriptors: Invalid argument
Dec 21 23:52:00.106 [warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details.
Dec 21 23:52:00.106 [err] Reading config failed--see warnings above.
```
Note that the user *was* using the alpha but also gets the same result using the stable 6.0.8 release.
I also noted that there have been issues with OSX and setrlimit before: https://gitweb.torproject.org/tor.git/tree/src/common/compat.c?h=release-0.2.8#n1742
```
/* On some platforms, OPEN_MAX is the real limit, and getrlimit() is
* full of nasty lies. I'm looking at you, OSX 10.5.... */
```
The original stack exchange ticket can be seen here: https://tor.stackexchange.com/questions/13466/tor-unexpectedly-exited-cant-launch-tor-browser-at-all-anymore-for-no-apparent?noredirect=1#comment14480_13466
I'm willing to ask the user for more information if required and a stackexchange login with 50+ rep isn't available.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22605sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/to...2020-06-13T15:10:10Ztoralfsandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/got this today at a stable hardened Gentoo linux server:
```
mr-fox ~ # cat x.log
Jun 14 21:19:55.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/ (on Tor 0.3.1.3-alpha dc47d936d47ffc25)...got this today at a stable hardened Gentoo linux server:
```
mr-fox ~ # cat x.log
Jun 14 21:19:55.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/ (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
Jun 14 21:19:55.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/ (on Tor 0.3.1.3-alpha dc47d936d47ffc25)
============================================================ T= 1497467995
(Sandbox) Caught a bad syscall attempt (syscall open)
/usr/bin/tor(+0x18e5f5)[0x55ec9b7a75f5]
/lib64/libc.so.6(opendir+0x11)[0x7f5dfe271421]
/lib64/libc.so.6(opendir+0x11)[0x7f5dfe271421]
/usr/bin/tor(tor_listdir+0x32)[0x55ec9b7a32e2]
/usr/bin/tor(+0x179080)[0x55ec9b792080]
/usr/bin/tor(config_get_lines_include+0x38)[0x55ec9b792258]
/usr/bin/tor(options_init_from_string+0x1df)[0x55ec9b716d0f]
/usr/bin/tor(options_init_from_torrc+0x1f1)[0x55ec9b717221]
/usr/bin/tor(+0x4f399)[0x55ec9b668399]
/usr/lib64/libevent-2.1.so.6(+0x23749)[0x7f5dff649749]
/usr/lib64/libevent-2.1.so.6(event_base_loop+0x57f)[0x7f5dff64a5ef]
/usr/bin/tor(do_main_loop+0x24d)[0x55ec9b66693d]
/usr/bin/tor(tor_main+0x1c3d)[0x55ec9b66a32d]
/usr/bin/tor(main+0x28)[0x55ec9b661d18]
/lib64/libc.so.6(__libc_start_main+0xfc)[0x7f5dfe1d972c]
/usr/bin/tor(_start+0x29)[0x55ec9b661d69]
```Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/22737CID 1401591: errant memset in cell_pack().2020-06-13T15:10:46ZNick MathewsonCID 1401591: errant memset in cell_pack().There's a new issue that coverity found. I believe it is harmless
in practice, and I've had other network-team member sanity-check my
analysis, but we should fix it anyway.
The issue is in cell_pack, in connection_or.c. Here is the fu...There's a new issue that coverity found. I believe it is harmless
in practice, and I've had other network-team member sanity-check my
analysis, but we should fix it anyway.
The issue is in cell_pack, in connection_or.c. Here is the function
in question (comment is added):
```
void
cell_pack(packed_cell_t *dst, const cell_t *src, int wide_circ_ids)
{
char *dest = dst->body;
if (wide_circ_ids) {
set_uint32(dest, htonl(src->circ_id));
dest += 4;
} else {
set_uint16(dest, htons(src->circ_id));
dest += 2;
memset(dest+CELL_MAX_NETWORK_SIZE-2, 0, 2); // <--- PROBLEM memset()!
}
set_uint8(dest, src->command);
memcpy(dest+1, src->payload, CELL_PAYLOAD_SIZE);
}
```
Background: the format of a cell is like this:
```
xx circuit_id;
u8 command;
u8 payload[509];
```
For a long time, circuit_id was two bytes; now it's 4 bytes
(whenever wide_circ_ids is true). When we are using wide_circ_ids,
then a packed cell is 514 bytes long; when we aren't, then a packed
cell 512 bytes long.
The packed_cell_t.body field is large enough to hold a packed cell
of maximum size (514 bytes). When we are sending a 512-byte cell,
we want the final two bytes of the cell to be cleared. That's why we
call the memset there.
But as you can see with some arithmetic, the memset is wrong: it
should come before "dest += 2", not after. This mistake causes it
to overwrite the two bytes _after_ packed_cell_t.body.
This mistake causes two possible bugs. I believe they are both
harmless IRL.
BUG 1: memory stomping
When we call the memset, we are overwriting two 0 bytes past the end
of packed_cell_t.body. But I think that's harmless in practice,
because the definition of packed_cell_t is:
```
#define CELL_MAX_NETWORK_SIZE 514
// ...
typedef struct packed_cell_t {
TOR_SIMPLEQ_ENTRY(packed_cell_t) next;
char body[CELL_MAX_NETWORK_SIZE];
uint32_t inserted_time;
} packed_cell_t;
```
So we will overwrite either two bytes of inserted_time, or two bytes
of padding, depending on how the platform handles alignment.
If we're overwriting padding, that's safe.
If we are overwriting the inserted_time field, that's also safe: In
every case where we call cell_pack() from connection_or.c, we ignore
the inserted_time field. When we call cell_pack() from relay.c, we
don't set or use inserted_time until right after we have called
cell_pack(). SO I believe we're safe in that case too.
BUG 2: memory exposure
The original reason for this memset was to avoid the possibility of
accidentally leaking uninitialized ram to the network. Now
remember, if wide_circ_ids is false on a connection, we shouldn't
actually be sending more than 512 bytes of packed_cell_t.body, so
these two bytes can only leak to the network if there is another bug
somewhere else in the code that sends more data than is correct.
Fortunately, in relay.c, where we allocate packed_cell_t in
packed_cell_new() , we allocate it with tor_malloc_zero(), which
clears the RAM, right before we call cell_pack. So those
packed_cell_t.body bytes can't leak any information.
That leaves the two calls to cell_pack() in connection_or.c, which
use stack-alocated packed_cell_t instances.
In or_handshake_state_record_cell(), we pass the cell's contents to
crypto_digest_add_bytes(). When we do so, we get the number of
bytes to pass using the same setting of wide_circ_ids as we passed
to cell_pack(). So I believe that's safe.
In connection_or_write_cell_to_buf(), we also use the same setting
of wide_circ_ids in both calls. So I believe that's safe too.
CONCLUSION:
I think this bug can't actually leak any data or overwrite anything
of value. Still we should fix it.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22753Resolve TROVE-2017-006: Regression in guard family avoidance in 0.3.0 series2020-06-13T15:10:53ZNick MathewsonResolve TROVE-2017-006: Regression in guard family avoidance in 0.3.0 seriesIn 0.3.0, when I revised the guard selection code, I got the "don't use your exit as first-hop if even if it's your guard" logic right, but I accidentally omitted "don't use anything in the exit's family as a guard."
The impact here is...In 0.3.0, when I revised the guard selection code, I got the "don't use your exit as first-hop if even if it's your guard" logic right, but I accidentally omitted "don't use anything in the exit's family as a guard."
The impact here is that some circuits will still use a guard on the same circuit as an exit even when the two are in the same family.
(Putting this issue up on the tracker now because knowing about it does not (much) help an attacker exploit it.)
This is TROVE-2017-006 and CVE-2017-0377.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22801Warnings from isnan, isinfinite, signbit on mingw2020-06-13T15:11:09ZNick MathewsonWarnings from isnan, isinfinite, signbit on mingwWe're seeing these on jenkins. They're somewhat annoying. I have a fix. Making this ticket for tracking purposes.
```
11:32:49 In file included from src/common/util.c:44:0:
11:32:49 src/common/util.c: In function 'clamp_double_to_int...We're seeing these on jenkins. They're somewhat annoying. I have a fix. Making this ticket for tracking purposes.
```
11:32:49 In file included from src/common/util.c:44:0:
11:32:49 src/common/util.c: In function 'clamp_double_to_int64':
11:32:49 src/common/util.c:5602:13: error: conversion to 'float' from 'double' may alter its value [-Werror=float-conversion]
11:32:49 if (isnan(number)) {
11:32:49 ^
11:32:49 src/common/util.c:5620:16: error: conversion to 'float' from 'double' may alter its value [-Werror=float-conversion]
11:32:49 if (isfinite(number) && exponent <= 63) {
11:32:49 ^
11:32:49 src/common/util.c:5625:18: error: conversion to 'float' from 'double' may alter its value [-Werror=float-conversion]
11:32:49 return signbit(number) ? INT64_MIN : INT64_MAX;
11:32:49 ^
11:32:50 cc1: all warnings being treated as errors
```Tor: 0.2.9.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/22895Unused variables in donna's SSE2 header2020-06-13T15:11:35ZcypherpunksUnused variables in donna's SSE2 headerFWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).FWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22915clang 4.0 double promotion warnings in clamp_double_to_int64()2020-06-13T15:11:41ZNick Mathewsonclang 4.0 double promotion warnings in clamp_double_to_int64()Just upgraded to clang 4.0, and I'm seeing this:
```
CC src/common/util.o
src/common/util.c:5612:13: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
i...Just upgraded to clang 4.0, and I'm seeing this:
```
CC src/common/util.o
src/common/util.c:5612:13: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
if (isnan(number)) {
~~~~~~^~~~~~~
/usr/include/math.h:385:46: note: expanded from macro 'isnan'
# define isnan(x) __MATH_TG ((x), __isnan, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
src/common/util.c:5630:16: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
if (isfinite(number) && exponent <= 63) {
~~~~~~~~~^~~~~~~
/usr/include/math.h:370:50: note: expanded from macro 'isfinite'
# define isfinite(x) __MATH_TG ((x), __finite, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
src/common/util.c:5635:18: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
return signbit(number) ? INT64_MIN : INT64_MAX;
~~~~~~~~^~~~~~~
/usr/include/math.h:361:58: note: expanded from macro 'signbit'
# define signbit(x) __MATH_TG ((x), __builtin_signbit, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
3 errors generated.
```Tor: 0.3.2.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/23030Review coverity build warnings2020-06-13T15:12:04ZNick MathewsonReview coverity build warningsCoverity emits a big pile of build warnings because of our BUG macro. Let's see if we can fix that. They look like this:
```
"/home/torcoverity/src/tor/cov-int/emit/totoro.wangafu.net/config/fc74ea42bbd56
ee35d2b17ca574b8e9b/...Coverity emits a big pile of build warnings because of our BUG macro. Let's see if we can fix that. They look like this:
```
"/home/torcoverity/src/tor/cov-int/emit/totoro.wangafu.net/config/fc74ea42bbd56
ee35d2b17ca574b8e9b/gcc-config-0/coverity-compiler-compat.h", line
1627: warning #41: expression must have arithmetic or pointer type
#nodef BUG() __coverity_panic__()
```
Also, there are quite a few of these:
```
"src/common/util.c", line 1169: warning #1563: function "tor_parse_long" not
emitted, consider modeling it or review parse diagnostics to improve
fidelity
tor_parse_long(const char *s, int base, long min, long max,
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23078hs: Forgotten log_warn for prop224 intro point2020-06-13T15:12:12ZDavid Gouletdgoulet@torproject.orghs: Forgotten log_warn for prop224 intro pointTurns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torpr...Turns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torproject.org/pipermail/tor-relays/2017-August/012689.html
As far as I can tell, it seems the only warning that is misplaced and that one is unneeded.
However, I might want to take the opportunity to change 3 `log_warn()` and put them to protocol warning level instead.
```
log_warn(LD_REND, "Unable to send INTRODUCE2 cell to the service.");
...
log_warn(LD_REND, "Unable to send an INTRODUCE ACK status %d to client.",
status);
...
log_warn(LD_BUG, "Couldn't send INTRO_ESTABLISHED cell.");
```
They've been introduced in `tor-0.3.0.1-alpha` and `tor-0.3.0.2-alpha`.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23097The circuit timeout prediction is not working properly2020-06-13T15:12:18ZDavid Gouletdgoulet@torproject.orgThe circuit timeout prediction is not working properlyDuring prop224 service testing (#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new ones for internal use (prediction) but set their timeout to 1 s...During prop224 service testing (#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new ones for internal use (prediction) but set their timeout to 1 sec which leads to closing the circuit 30 sec later (`NewCircuitPeriod` defaults to 30 sec).
Condensed log info:
```
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 320 that has been unused for 27997 msec.
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 318 that has been unused for 29997 msec.
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 319 that has been unused for 28979 msec.
Aug 03 19:59:30.000 [info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another internal circ for my hidden service.
Aug 03 19:59:30.000 [info] origin_circuit_new(): Circuit 321 chose an idle timeout of 1 based on 0 seconds of predictive building remaining.
...
Aug 03 20:00:01.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 321 that has been unused for 30991 msec.
```
So notice the circuit 321 with a timeout of 1 sec and then being closed 30 sec later... Basically, it's looping like that non stop. What I think is happening is this:
`predicted_ports_prediction_time_remaining()` returns 0 so the following computation always results in 1 sec (in `origin_circuit_new()`):
```
int prediction_time_remaining =
predicted_ports_prediction_time_remaining(time(NULL));
circ->circuit_idle_timeout = prediction_time_remaining+1+
crypto_rand_int(1+prediction_time_remaining/20);
```
We call `rep_hist_note_used_internal()` in the hs subsystem when we launch intro point and rendezvous circuits. That function sets `last_prediction_add_time = now`. Which is what we want because then `predicted_ports_prediction_time_remaining()` computes a `idle_delta` that is below the `prediction_timeout` (set between 30 and 60 mins by default, see `channelpadding_get_circuits_available_timeout()`).
Which means that after let's say 61 min for a `prediction_timeout = 60min`, `idle_delta` becomes bigger than `prediction_timeout` and thus returning 0 everytime ultimately making every new circuit timeout to 1 sec. See why below:
```
int
predicted_ports_prediction_time_remaining(time_t now)
{
time_t idle_delta = now - last_prediction_add_time;
/* Protect against overflow of return value. This can happen if the clock
* jumps backwards in time. Update the last prediction time (aka last
* active time) to prevent it. This update is preferable to using monotonic
* time because it prevents clock jumps into the past from simply causing
* very long idle timeouts while the monotonic time stands still. */
if (last_prediction_add_time > now) {
last_prediction_add_time = now;
idle_delta = 0;
}
/* Protect against underflow of the return value. This can happen for very
* large periods of inactivity/system sleep. */
if (idle_delta > prediction_timeout)
return 0;
[RIGHT HERE, we return 0]
...
```
This is pretty bad because it means that every HS that sees no client for at least 30 to 60 min, will enter this loop of create/close circuits raising flags at the Guard but also putting pressure on the network.
Seems that this was introduced with the channel padding in tor-0.3.1.1-alpha.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23105Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.2020-06-13T15:12:23ZcypherpunksBug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.Got the following warn msg while browsing,
```
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL. Dropping. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
```Got the following warn msg while browsing,
```
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL. Dropping. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
```Tor: 0.3.3.x-finalhttps://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/23234Possible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53...2020-06-13T15:12:42Zs7rPossible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation warn)After an upgrade to latest git master `Tor 0.3.2.0-alpha-dev (git-257f50b22fbaf9c9)` got some bootstrapping complaints that seam to be triggered by the DirGuard being offline. This is a bridge, and was taken offline few days ago by a pow...After an upgrade to latest git master `Tor 0.3.2.0-alpha-dev (git-257f50b22fbaf9c9)` got some bootstrapping complaints that seam to be triggered by the DirGuard being offline. This is a bridge, and was taken offline few days ago by a power failure. The hard drive was not affected so the files in datadirectory were kept.
```
Aug 14 00:28:57.000 [notice] Starting with guard context "default"
Aug 14 00:28:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 14 00:28:57.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 1; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 3; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 2 connections have failed:
Aug 14 00:28:58.000 [warn] 2 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 4; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 3 connections have failed:
Aug 14 00:28:58.000 [warn] 3 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [notice] Bootstrapped 53%: Loading relay descriptors
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 2; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 5 connections have failed:
Aug 14 00:28:58.000 [warn] 5 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 4; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 7 connections have failed:
Aug 14 00:28:58.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 6; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 9 connections have failed:
Aug 14 00:28:58.000 [warn] 9 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 10 connections have failed:
Aug 14 00:28:58.000 [warn] 10 connections died in state connect()ing with SSL state (No SSL object)
```
The complaints stop when Bootstrap reaches 80%, but the "missing descriptors from some of our primary entry guards" follows immediately:
```
Aug 14 00:29:10.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 14 00:29:10.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Aug 14 00:29:11.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Aug 14 00:29:12.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 14 00:29:12.000 [notice] Bootstrapped 100%: Done
Aug 14 00:29:12.000 [notice] Now checking whether ORPort xx.br.id.ge:yy is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 14 00:29:13.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for some of our primary entry guards
Aug 14 00:29:13.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Aug 14 00:29:13.000 [notice] We now have enough directory information to build circuits.
Aug 14 00:29:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 14 00:29:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
```
One problem is: How come it just bootstrapped 100%, and 1 second later Tor realizes it is missing descriptors for some of our primary guards?
Second: Why does it report no route to host and SSL connections failing in state connect if the internet connection is working good and the problem is just at the endpoint? Even if the problem is not at the endpoint this particular log message is awfully confusing.Tor: unspecified