Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:48:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40174tracing-instrumentation-usdt fails to build: error: use of undeclared identif...2022-07-07T00:48:31Zyurivicttracing-instrumentation-usdt fails to build: error: use of undeclared identifier 'tor_circuit'```
src/core/or/circuitlist.c:571:13: error: use of undeclared identifier 'tor_circuit'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
./src/lib/trace/events.h:45:25: note: expanded from mac...```
src/core/or/circuitlist.c:571:13: error: use of undeclared identifier 'tor_circuit'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
./src/lib/trace/events.h:45:25: note: expanded from macro 'TR_SUBSYS'
#define TR_SUBSYS(name) tor_ ## name
^
<scratch space>:130:1: note: expanded from here
tor_circuit
^
src/core/or/circuitlist.c:571:39: error: use of undeclared identifier 'change_state'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
src/core/or/circuitbuild.c:503:3: warning: implicit declaration of function 'STAP_PROBEV' is invalid in C99 [-Wimplicit-function-declaration]
tor_trace(TR_SUBSYS(circuit), TR_EV(establish), circ);
^
./src/lib/trace/events.h:53:5: src/core/or/circuitlist.c:1086:3: warning: implicit declaration of function 'STAP_PROBEV' is invalid in C99 [-Wimplicit-function-declaration]
tor_trace(TR_SUBSYS(circuit), TR_EV(new_origin), circ);
^
```
^
0.4.5.1-alpha on FreeBSD 12.2
Additionally, the file doc/HACKING/Tracing.md mentioned in the changelog https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.4.5.1-alpha doesn't exist.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40173tracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file...2022-07-07T00:48:31Zyurivicttracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file not found```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40172Build failure on macOS on master2021-07-09T17:30:28ZMatthew FinkelBuild failure on macOS on masterIn tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) ...In tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) is causing this. Attached is the latest build log when building commit df1637600469 (tip of master, at build time).
[tor-osx-x86_64.log](/uploads/f83b8ec1bc057c5cd7f8774936b35aa5/tor-osx-x86_64.log)Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40167ExitNodes not respected on all websites2022-07-07T00:48:31ZwhatthephilExitNodes not respected on all websitesI described this issue here:
https://tor.stackexchange.com/questions/21671/exitnodes-not-respected-on-particular-website
ExitNodes works for me on most websites but doesn't on this one website. It used to work fine until I updated Tor t...I described this issue here:
https://tor.stackexchange.com/questions/21671/exitnodes-not-respected-on-particular-website
ExitNodes works for me on most websites but doesn't on this one website. It used to work fine until I updated Tor to version 10.0.1. I tried version 10.5 and have the same issue.Tor: 0.4.5.x-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40071Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NON...2021-07-09T17:30:28ZLX1Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NONE) | Don't know my address while generating descriptor**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
He...**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
Hello. **After update alpha dev**:
> log: "Don't know my address while generating descriptor"
> https://metrics.torproject.org/rs.html#search/agileresearchlab but from the same location stable relay runs normally
I have 2 relays alpha/stable in the same location / 1 fix IP.
This happened after the update, only alpha bridge, stable bridge running normally.
Until then, everything was normal > 1 IP == 2x bridge obfs4.
OS: Debian
I provide alpha just for development research primarily..![obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor](/uploads/97b4a23f12f8b13a4807fc3949e3177b/obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor.jpg)
![_source__METHOD_NONE_](/uploads/8cb0281c7956df60fb0eaf5d84bf63d4/_source__METHOD_NONE_.jpg)Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40017Inbuf for outgoing SOCKS 4 proxy not cleared before reading from OR connection2022-07-07T00:48:30ZoparaInbuf for outgoing SOCKS 4 proxy not cleared before reading from OR connectionWhen configured to use an outgoing SOCKS 4 proxy (as set with `Socks4Proxy ip:port`), tor does not clear the connection buffer after the SOCKS handshake and before reading bytes from the OR connection. A proxy can send extra characters a...When configured to use an outgoing SOCKS 4 proxy (as set with `Socks4Proxy ip:port`), tor does not clear the connection buffer after the SOCKS handshake and before reading bytes from the OR connection. A proxy can send extra characters at the end of the handshake which will be stored on the OR connection inbuf as if they were authenticated bytes from the first hop.
This is not actually exploitable because of a check in `connection_or_process_inbuf()`, which will close the connection if it sees that there are bytes on the inbuf while the connection is in the TLS handshaking state. This check was originally designed to protect relays and not clients, but luckily it actually protects the client in this case as well.
```C
/* This check was necessary with 0.2.2, when the TLS_SERVER_RENEGOTIATING
* check would otherwise just let data accumulate. It serves no purpose
* in 0.2.3.
*
* XXXX Remove this check once we verify that the above paragraph is
* 100% true. */
if (buf_datalen(conn->base_.inbuf) > MAX_OR_INBUF_WHEN_NONOPEN) {
log_fn(LOG_PROTOCOL_WARN, LD_NET, "Accumulated too much data (%d bytes) "
"on nonopen OR connection %s %s:%u in state %s; closing.",
(int)buf_datalen(conn->base_.inbuf),
connection_or_nonopen_was_started_here(conn) ? "to" : "from",
conn->base_.address, conn->base_.port,
conn_state_to_string(conn->base_.type, conn->base_.state));
connection_or_close_for_error(conn, 0);
ret = -1;
}
```
I think that the comments here should be changed to show that this check is still important, and it would be good to also clear the inbuf when transitioning out of the `OR_CONN_STATE_PROXY_HANDSHAKING` state. The best solution would probably be to not use a single buffer for both authenticated and unauthenticated data, but this would probably take more work. I have also not looked at the other proxy types, but the SOCKS 5 proxy looks okay at first glance.
If you remove the check above (as mentioned in the comment), a SOCKS 4 proxy that appends for example `\x00\x00\x07\x00\x00\x01` (a VERSIONS cell) to the proxy reply will cause the tor client to log:
```
channel_tls_process_versions_cell(): Couldn't find a version in common between my version list and the list in the VERSIONS cell; closing connection.
```
This only causes the client to drop the connection (so the client can't connect to the tor network), but as the proxy would be able to bypass the TLS authentication for the first cells on a connection (*if the check above were removed*) and make the client think that it received cells that the first hop didn't send, there could potentially be other interesting things you could do with other cell types.Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33850log rotation for /var/log/tor/debug.log did not close handle to old file afte...2020-10-29T15:21:31ZTraclog rotation for /var/log/tor/debug.log did not close handle to old file after compressionso / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabl...so / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabled:
Log notice file /var/log/tor/notices.log
Log debug file /var/log/tor/debug.log
**Trac**:
**Username**: MaKoTorTor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33624Static building tor with openssl does not work2021-02-06T05:05:34ZDavid Gouletdgoulet@torproject.orgStatic building tor with openssl does not workWe have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which ...We have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which we need to build tor with openssl and libevent statically.
At current master, this is not working for build system and code reasons.
This ticket is to address it all so we can close all other related tickets.
Here is a raw tor.git diff that makes this work. There is still some think to consider especially with the `OPENSSL_VERSION`:
https://gitlab.torproject.org/dgoulet/tor-library-size/blob/master/tor.diffTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32666BUG: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/cir...2021-01-21T17:28:19ZcypherpunksBUG: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/circuitbuild.c:2663. (Stack trace not available) (on Tor 0.4.1.5 439ca48989ece545)Got this in orbot After startup.
```
NOTICE: Bootstrapped 100% (done): Done
Ignoring start request, already started.
WARN: tor_bug_occurred_: Bug: src/core/or/circuitbuild.c:2663: onion_extend_cpath: Non-fatal assertion info failed. (on...Got this in orbot After startup.
```
NOTICE: Bootstrapped 100% (done): Done
Ignoring start request, already started.
WARN: tor_bug_occurred_: Bug: src/core/or/circuitbuild.c:2663: onion_extend_cpath: Non-fatal assertion info failed. (on Tor 0.4.1.5 439ca48989ece545)
WARN: Bug: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/circuitbuild.c:2663. (Stack trace not available) (on Tor 0.4.1.5 439ca48989ece545)
WARN: Failed to find node for hop #2 of our path. Discarding this circuit.
NOTICE: Our circuit 0 (id: 15) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug.
```
Orbot 16.1.2rc2Tor: 0.4.5.x-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32178Tor adds trailing space character to log events2020-11-03T14:07:14ZRoger DingledineTor adds trailing space character to log eventsFirst noticed in legacy/trac#32164, where Tor Browser's "view of Tor logs" has a bonus space at the end of every line.
I believe it's Tor adding the space. This super simple hack:
```
diff --git a/src/feature/control/control_events.c b/...First noticed in legacy/trac#32164, where Tor Browser's "view of Tor logs" has a bonus space at the end of every line.
I believe it's Tor adding the space. This super simple hack:
```
diff --git a/src/feature/control/control_events.c b/src/feature/control/control_events.c
index 82ea943999..5ddfffeee8 100644
--- a/src/feature/control/control_events.c
+++ b/src/feature/control/control_events.c
@@ -1328,6 +1328,7 @@ control_event_logmsg(int severity, log_domain_mask_t domain, const char *msg)
default: s = "UnknownLogSeverity"; break;
}
++disable_log_messages;
+ printf("Sending \"650 %s %s\"\n", s, b?b:msg);
send_control_event(event, "650 %s %s\r\n", s, b?b:msg);
if (severity == LOG_ERR) {
/* Force a flush, since we may be about to die horribly */
```
shows it:
```
Sending "650 INFO circuit_free_(): Circuit 0 (id: 4) has been freed. "
```
I believe it comes from this snippet in control_event_logmsg():
```
if (strchr(msg, '\n')) {
char *cp;
b = tor_strdup(msg);
for (cp = b; *cp; ++cp)
if (*cp == '\r' || *cp == '\n')
*cp = ' ';
}
```
That is, we send in log lines that have \n in them, and the function helpfully turns the \n into a ' '.
Bug went into Tor 0.1.1.1-alpha in commit c2f6fe9b (way back in the days of the v0 control protocol).Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25528When ClientTransportPlugin is missing, tor connects directly to bridge addres...2022-09-05T17:50:35ZDavid Fifielddcf@torproject.orgWhen ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport nameStart `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode...Start `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0
```
See a connection to 83.212.101.3:50002, despite that, lacking a `ClientTransportPlugin` line, tor doesn't know how to connect to an "obfs4" bridge.
Another way to see it is with this torrc, using a phony address like meek and snowflake do:
```
UseBridges 1
Bridge dummy 0.0.3.0:1
```
tor actually tries to connect to the 0.0.3.0:1 address, and fails with an "Invalid argument" error:
```
[warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Invalid argument; RESOURCELIMIT; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.3.0:1)
```
I expected instead that tor would not try to connect to the address, but rather would show [this error message](https://gitweb.torproject.org/tor.git/tree/src/or/connection_or.c?h=tor-0.3.2.10#n1231):
> We were supposed to connect to bridge 'X' using pluggable transport 'Y', but we can't find a pluggable transport proxy supporting 'Y'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
The problem exists in both 0.2.9.14 and 0.3.4.0-alpha-dev, which are the two versions I tested.
I found this problem through a user report at legacy/trac#25527. The user was trying to run the Tor Browser tor, but they were in the wrong directory, so they were only getting torrc and not torrc-defaults. torrc contains `UseBridges` and `Bridge`, but torrc-defaults contains `ClientTransportPlugin`.
There was another ticket about tor occasionally connecting to PT bridges as if they were ordinary guards: legacy/trac#20532. It may be the same as this. At legacy/trac#25527 I speculated that the problem might have been caused by cached `Guard` entries, but that doesn't seem to be the case. All you have to do is omit the `ClientTransportPlugin` line.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/4692If only a working static OpenSSL is available, ./configure fails2020-10-29T15:25:52ZSteven MurdochIf only a working static OpenSSL is available, ./configure failsIf OpenSSL is available, but only the statically linked version works, ./configure will fail. This is because the autoconf test program will be by default built dynamically, at least on Windows, even if --enable-static-openssl is set. Th...If OpenSSL is available, but only the statically linked version works, ./configure will fail. This is because the autoconf test program will be by default built dynamically, at least on Windows, even if --enable-static-openssl is set. The attached patch (appears to) resolve this problem on Windows.
However, the patch doesn't work on MacOS X because passing -static to the compiler causes it to fail with the error "ld: library not found for -lcrt0.o". I presume MacOS X can't produce fully static binaries for whatever reason.
What I'd really like to do is pass "$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a" into the link path of the test program built by TOR_SEARCH_LIBRARY(openssl, ...). However, $TOR_LIBDIR_ is being set by TOR_SEARCH_LIBRARY so there is a chicken and egg problem here which I'm not sure how to resolve.
These tests were done on Tor version e4cebb76c5577b1a39b752cc694147e929662c4a.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40285Bug: 2-hop circuit with purpose 5 has no guard state2022-07-07T00:47:09ZRoger DingledineBug: 2-hop circuit with purpose 5 has no guard stateWhen I issue an "extendcircuit 0 A,B" command with my controller, and the circuit gets built, my Tor logs a line like:
```
Feb 09 20:36:44.400 [warn] circuit_build_no_more_hops(): Bug: 2-hop circuit 0x5558a75e2190 with purpose 5 has no g...When I issue an "extendcircuit 0 A,B" command with my controller, and the circuit gets built, my Tor logs a line like:
```
Feb 09 20:36:44.400 [warn] circuit_build_no_more_hops(): Bug: 2-hop circuit 0x5558a75e2190 with purpose 5 has no guard state (on Tor 0.4.5.5-rc-dev f420eacf1858220f)
```
My extendprobe tester (https://gitlab.torproject.org/tpo/network-health/team/-/issues/16) makes many such circuits, and ends up with many such Bug lines.
See #24966 for a past version of this bug that got closed.
This issue isn't a big deal, except for the log spam, and maybe we still (hopefully we still?) have an invariant goal where Tor isn't supposed to issue any "Bug" lines during ordinary expected behavior.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40204Travis chutney tests are borked by two bad commits2021-02-05T21:03:36ZGeorge KadianakisTravis chutney tests are borked by two bad commitsSeems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two comm...Seems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two commits are 1588767e655f87f49cf0f71d6e604117be52a135 and 4382e977f74e41f65170b4d9292678859c9e521f. Reverting just one of them won't do it and both of them need to be reverted for the tests to pass.
We should fix this so that we start getting a proper CI again.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40189"tor-gencert --create-identity-key" fails with no clear error message if pass...2022-07-07T00:48:31ZRoger Dingledine"tor-gencert --create-identity-key" fails with no clear error message if passphrase is empty or shortRun tor-gencert to make a new key, but leave the PEM pass phrase empty (just hit enter):
```
$ ./tor-gencert --create-identity-key
Enter PEM pass phrase:
Nov 15 15:32:59.730 [err] Couldn't write identity key to ./authority_identity_key
N...Run tor-gencert to make a new key, but leave the PEM pass phrase empty (just hit enter):
```
$ ./tor-gencert --create-identity-key
Enter PEM pass phrase:
Nov 15 15:32:59.730 [err] Couldn't write identity key to ./authority_identity_key
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: result too small (in UI routines:UI_set_result_ex)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: processing error (in UI routines:UI_process)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: problems getting password (in PEM routines:PEM_def_callback)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: read key (in PEM routines:do_pk8pkey)
```
It seems to me that having an empty pass phrase should work; but if we want it to not work, we should say that as an error message.
(Found by tech-exorcist on #tor)
In fact, I just tried it with short passphrases, and they also fail with these cryptic error messages. So it sounds like maybe we have a secret minimum passphrase length or something?Tor: 0.4.6.x-freezeNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/19011Use of maxunmeasuredbw and bwweightscale is broken in consensus2021-09-16T14:33:29ZNick MathewsonUse of maxunmeasuredbw and bwweightscale is broken in consensusWhile refactoring, I noticed this code in dirvote.c:
```
if (params) {
if (strcmpstart(params, "bwweightscale=") == 0)
bw_weight_param = params;
else
bw_weight_param = strstr(params, " bwweightscale=");
...While refactoring, I noticed this code in dirvote.c:
```
if (params) {
if (strcmpstart(params, "bwweightscale=") == 0)
bw_weight_param = params;
else
bw_weight_param = strstr(params, " bwweightscale=");
}
if (bw_weight_param) {
int ok=0;
char *eq = strchr(bw_weight_param, '=');
if (eq) {
weight_scale = tor_parse_long(eq+1, 10, 1, INT32_MAX, &ok,
NULL);
if (!ok) {
log_warn(LD_DIR, "Bad element '%s' in bw weight param",
escaped(bw_weight_param));
weight_scale = BW_WEIGHT_SCALE;
}
} else {
log_warn(LD_DIR, "Bad element '%s' in bw weight param",
escaped(bw_weight_param));
weight_scale = BW_WEIGHT_SCALE;
}
}
```
Looking at the use of tor_parse_ulong(). Since "next" is NULL, any unconverted characters should make it give an error, making us use the default value.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40356Leaksanitizer detected memory leak with Tor Tor 0.4.6.1-alpha-dev (git-769d54...2022-07-07T00:47:10ZGeorg KoppenLeaksanitizer detected memory leak with Tor Tor 0.4.6.1-alpha-dev (git-769d54c5d7933ccb)I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser. No special usage, no bridges. Just normal browsing in a bunch of tabs and closing the browser after it had been running a full day:
```
Direct lea...I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser. No special usage, no bridges. Just normal browsing in a bunch of tabs and closing the browser after it had been running a full day:
```
Direct leak of 392 byte(s) in 7 object(s) allocated from:
#0 0x7f77ac8bae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x56288c6b1778 in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x56288c6b1810 in tor_malloc_zero_ ../src/lib/malloc/malloc.c:71
#3 0x56288c89354d in cache_client_desc_new ../src/feature/hs/hs_cache.c:460
#4 0x56288c89354d in hs_cache_store_as_client ../src/feature/hs/hs_cache.c:873
#5 0x56288c8a2dd5 in client_dir_fetch_200 ../src/feature/hs/hs_client.c:1463
#6 0x56288c8a2dd5 in hs_client_dir_fetch_done ../src/feature/hs/hs_client.c:2379
#7 0x56288c834fa8 in handle_response_fetch_hsdesc_v3 ../src/feature/dirclient/dirclient.c:2721
#8 0x56288c834fa8 in connection_dir_client_reached_eof ../src/feature/dirclient/dirclient.c:2139
#9 0x56288c834fa8 in connection_dir_reached_eof ../src/feature/dirclient/dirclient.c:2787
#10 0x56288c7d1ff1 in connection_reached_eof ../src/core/mainloop/connection.c:5243
#11 0x56288c7d1ff1 in connection_handle_read_impl ../src/core/mainloop/connection.c:4014
#12 0x56288c58c240 in conn_read_callback ../src/core/mainloop/mainloop.c:891
#13 0x7f77ac47c22e (TorBrowser/Tor/libevent-2.1.so.7+0x2322e)
```
I am attaching the whole LeakSanitizer output, too.Tor: 0.4.6.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40341Windows 32-bit build broken with introduction of `overload_happened_recently(...2022-07-07T00:47:10ZAlexander Færøyahf@torproject.orgWindows 32-bit build broken with introduction of `overload_happened_recently()` in rephist.cCommit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: I...Commit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: In function ‘overload_happened_recently’:
src/feature/stats/rephist.c:215:21: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (overload_time > approx_time() - 3600 * n_hours) {
```
See: https://travis-ci.org/github/ahf/tor-win32/jobs/763284597#L8775-L8777Tor: 0.4.6.x-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40337Relays don't actually notice bandwidth changes for a day2022-07-07T00:47:10ZRoger DingledineRelays don't actually notice bandwidth changes for a daySummary:
The current Tor has a bug where it assesses what "bandwidth observed" to put in its descriptor using only the bandwidth it saw itself do *yesterday* or earlier. This bug is especially sad for testing tor networks like chutney b...Summary:
The current Tor has a bug where it assesses what "bandwidth observed" to put in its descriptor using only the bandwidth it saw itself do *yesterday* or earlier. This bug is especially sad for testing tor networks like chutney because 24 hours ago is a long time for a chutney network; but it is also sad for relays bootstrapping in general because they don't behave in the way we thought they did.
Background:
Relays self-assess their own observed bandwidth by looking at the highest 10-second burst they've seen themselves do in either direction and picking the smaller of these two bursts. Specifically, they keep a set of previous largest bursts for past epochs, and a running count of the largest burst so far in the current epoch. When an epoch ends, they push all the epoch counts back one and store the current largest burst as the most recent epoch. When they want to know what number to put in the descriptor, they look for the highest burst among the past epochs, and they don't look at the current running largest.
At the dawn of time (Tor 0.0.8pre1 through Tor 0.2.6.3-alpha), the epochs lasted 15 minutes, so you'd need to wait up to 15 minutes before the current running total got stored and then counted for a new bandwidth estimate.
But then in Tor 0.2.6.3-alpha we moved that "15 minutes" up to "4 hours" (tor#13988, git commit 6830667d58), and then in Tor 0.3.2.6-alpha we moved from 4 hours to 24 hours (tor#23856, git commit 8be50ca3ea9). That's when things went bad for the relay capacity estimation: we continued only asking ourselves about past epochs, even though the past epochs got farther and farther in the past.
This feature is now at odds with, for example, the feature in check_descriptor_bandwidth_changed() that decides that big bandwidth shifts are only a good reason to publish a new descriptor if our uptime is less than 24 hours.Tor: 0.4.6.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40330Bug - Heartbeat log message does not consider the value of the "HeartbeatPeri...2022-07-07T00:47:10ZcypherpunksBug - Heartbeat log message does not consider the value of the "HeartbeatPeriod" value.The problem is in the file `/feature/stats/geoip_stats.c`, at the fonction `format_client_stats_heartbeat()`. The variable `n_hours` is hardcoded to 6 hours, which is the default value. Here is the changes I made to the fonction. I take ...The problem is in the file `/feature/stats/geoip_stats.c`, at the fonction `format_client_stats_heartbeat()`. The variable `n_hours` is hardcoded to 6 hours, which is the default value. Here is the changes I made to the fonction. I take the opportunity to do a little bit of refactoring. I did not know how to compile the project and test it, but I'm sure you will understand what I'm trying to do.
To fix this issue, `n_hours`, now renamed `n_heartbeat_period`, need to take the value of the `option->HeartbeatPeriod`, which is in seconds.
~~~
[- Line 1207 : const int n_hours = 6; -]
[+ Line 1207 : const int n_heartbeat_period = option->HeartbeatPeriod; +]
[- Line 1211 : unsigned cutoff = (unsigned)( (now-n_hours*3600)/60 ); -]
[+ Line 1211 : unsigned cutoff = (unsigned)( (now-n_heartbeat_period)/60 ); +]
[- Line 1228 : nhours, -]
[+ Line 1228 : n_heartbeat_period +]
~~~
The variable `out` could also be renamed `msg`.
~~~
[- Line 1208 : char *out = NULL; -]
[+ Line 1208 : char *msg = NULL; +]
[- Line 1226 : tor_asprintf(&out, "Heartbeat: " -]
[+ Line 1226 : tor_asprintf(&msg, "Heartbeat: " +]
[- Line 1231 : return out; -]
[+ Line 1231 : return msg; +]
~~~
A `clientmap_entry_t` is a `client`, so why not call it that way to make it more clear instead of `ent`.
~~~
[- Line 1210 : clientmap_entry_t **ent; -]
[+ Line 1210 : clientmap_entry_t **client; +]
[- Line 1217 : HT_FOREACH(ent, clientmap, &client_history) { -]
[+ Line 1217 : HT_FOREACH(client, clientmap, &client_history) { +]
[- Line 1219 : if ((*ent)->action != GEOIP_CLIENT_CONNECT) -]
[+ Line 1219 : if ((*client)->action != GEOIP_CLIENT_CONNECT) +]
[- Line 1221 : if ((*ent)->last_seen_in_minutes < cutoff) -]
[+ Line 1221 : if ((*client)->last_seen_in_minutes < cutoff) +]
~~~
Prettier `msg` :simple_smile:
~~~
[- Line 1226 : tor_asprintf(&out, "Heartbeat: " -]
[- Line 1227 : "In the last %d hours, I have seen %d unique clients.", -]
[- Line 1228 : n_hours, -]
[- Line 1229 : n_clients); -]
[+ Line 1226 : tor_asprintf(&msg, "Heartbeat: In the last %d hour%s, I have seen %u unique client%s.", +]
[+ Line 1227 : n_heartbeat_period*60*60, +]
[+ Line 1228 : n_heartbeat_period >= 60*60*2 ? "s" : "", +]
[+ Line 1229 : n_clients, +]
[+ Line 1230 : n_clients > 1 ? "s" : ""); +]
~~~
Message to the moderator about my `GitLab Flavored Markdown` skills :
My last issue is **horrible** and this one will certainly be, because I can't validate the formating before submitting it! I'm so sorry.Tor: 0.4.6.x-stableNick MathewsonNick Mathewson