Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:22:51Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25452FAIL ../src/test/test_hs_service.c:420: assert(ip->time_to_expire OP_GE now +...2020-06-13T15:22:51ZGeorge KadianakisFAIL ../src/test/test_hs_service.c:420: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDS + 5)weasel reported the `test_service_intro_point()` test failing here:
```
ip = helper_create_service_ip();
tt_assert(ip);
/* Make sure the authentication keypair is not zeroes. */
tt_int_op(tor_mem_is_zero((const char *) &i...weasel reported the `test_service_intro_point()` test failing here:
```
ip = helper_create_service_ip();
tt_assert(ip);
/* Make sure the authentication keypair is not zeroes. */
tt_int_op(tor_mem_is_zero((const char *) &ip->auth_key_kp,
sizeof(ed25519_keypair_t)), OP_EQ, 0);
/* The introduce2_max MUST be in that range. */
tt_u64_op(ip->introduce2_max, OP_GE,
INTRO_POINT_MIN_LIFETIME_INTRODUCTIONS);
tt_u64_op(ip->introduce2_max, OP_LE,
INTRO_POINT_MAX_LIFETIME_INTRODUCTIONS);
/* Time to expire MUST also be in that range. We add 5 seconds because
* there could be a gap between setting now and the time taken in
* service_intro_point_new. On ARM, it can be surprisingly slow... */
tt_u64_op(ip->time_to_expire, OP_GE,
now + INTRO_POINT_LIFETIME_MIN_SECONDS + 5);
tt_u64_op(ip->time_to_expire, OP_LE,
now + INTRO_POINT_LIFETIME_MAX_SECONDS + 5);
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24814Tor relay killing UPC Connect Box2020-06-13T15:19:56ZTracTor relay killing UPC Connect BoxI'm running a Tor relay since some years on my Raspberry 3 (earlier on the raspi 2), but recently my internet connection started to have packet loss.
After checking with my ISP, who didn't find anything wrong, I discovered that it's prob...I'm running a Tor relay since some years on my Raspberry 3 (earlier on the raspi 2), but recently my internet connection started to have packet loss.
After checking with my ISP, who didn't find anything wrong, I discovered that it's probably because of too many open connections.
Running 'arm' on my relay, I see that I have:
Connections (2561 inbound, 2115 outbound, 5 circuit)
or:
netstat -an | wc -l
4897
Besides that my raspi is a tad slow, my internet connection is quite slow because of the 20% packet loss.
I've started now to work with the MaxAdvertisedBandwidth option (now set to 550 KB, but would like to offer 10 Mbit/s) and reduced that by nearly 50%, but so far without any positive result (might take a while to propagate?).
Anyway, my ISP UPC.ch only allows their own Connect Box (CB) to be connected. I'm running it in modem mode, so my router is actually doing the whole NAT, but that one has enough performance (tested it by directly connecting a client to the CB and still had packet loss.
I'm sure this is bad for the whole TOR network :(
I assume it might be because of the new blockades in the Arabic areas, as I have the problem since around 3 weeks in varying amounts.
**Trac**:
**Username**: patoTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24577Systemctl tor.service invalid - Tor does not restart on systemctl start tor c...2020-06-13T15:18:41ZTracSystemctl tor.service invalid - Tor does not restart on systemctl start tor commandPlease refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is...Please refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is running and not the actual tor program itself:
----
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=Anonymizing overlay network for TCP (multi-instance-master)
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
----
So regardless if the TOR process is actually running or not, tor.service always returns TRUE. This is Invalid. and As a result running: sudo systemctl start|stop tor does nothing as you can see here:
● tor.service - Anonymizing overlay network for TCP (multi-instance-master)
** Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 9min ago
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
So for the moment the temporary fix is:
Removing or renaming offending file /lib/systemd/system/tor.service and reloading the scripts w/ systemctl daemon-reload. because the actual and correct script to start tor is in /etc/init.d/tor
After this modifcation the resulting output of sudo systemctl status tor:
● tor.service - LSB: Starts The Onion Router daemon processes
** Loaded: loaded (/etc/init.d/tor; bad; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 26min ago
Docs: !man:systemd-sysv-generator(8)
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
I believe the tor script in /etc/init.d/tor is incorrectly attempting to start/stop tor through tor.service as well.
Please correct this as soon as possible thank you !
**Trac**:
**Username**: d3m0nkingxTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24503Rust build fails2020-06-13T16:07:55ZTracRust build failsWhen compiling it with rust support it will fail with:
checking rust crate dependencies... configure: error: Rust dependency directory ./src/ext/rust/ does not exist. Specify a dependency directory using the RUST_DEPENDENCIES variable or...When compiling it with rust support it will fail with:
checking rust crate dependencies... configure: error: Rust dependency directory ./src/ext/rust/ does not exist. Specify a dependency directory using the RUST_DEPENDENCIES variable or allow cargo to fetch crates using --enable-cargo-online-mode.
**Trac**:
**Username**: tortuxTor: 0.3.1.x-finalOndrej MikleOndrej Miklehttps://gitlab.torproject.org/legacy/trac/-/issues/24198(Sandbox) Caught a bad syscall attempt (syscall kill)2020-06-13T15:17:09ZGeorge Kadianakis(Sandbox) Caught a bad syscall attempt (syscall kill)`maint-0.3.2` is failing `make test-network-all` right now with:
```
============================================================ T= 1510233993
(Sandbox) Caught a bad syscall attempt (syscall kill)
/home/f/Computers/tor/mytor/src/or/tor(...`maint-0.3.2` is failing `make test-network-all` right now with:
```
============================================================ T= 1510233993
(Sandbox) Caught a bad syscall attempt (syscall kill)
/home/f/Computers/tor/mytor/src/or/tor(+0x19f21a)[0x55c60558821a]
/lib/x86_64-linux-gnu/libc.so.6(kill+0x7)[0x7fa9605d4317]
/lib/x86_64-linux-gnu/libc.so.6(kill+0x7)[0x7fa9605d4317]
/home/f/Computers/tor/mytor/src/or/tor(+0x1de69b)[0x55c6055c769b]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba)[0x7fa9618e79ba]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7fa9618e8537]
/home/f/Computers/tor/mytor/src/or/tor(do_main_loop+0x22d)[0x55c60543b90d]
/home/f/Computers/tor/mytor/src/or/tor(tor_main+0xe1d)[0x55c60543e5fd]
/home/f/Computers/tor/mytor/src/or/tor(main+0x19)[0x55c6054371f9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fa9605c12e1]
/home/f/Computers/tor/mytor/src/or/tor(_start+0x2a)[0x55c60543724a]
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24124[warn] Socks version -125 not recognized.2020-06-13T15:16:52Zyurivict271[warn] Socks version -125 not recognized.I spotted version 0.3.1.8 consuming 100% CPU in idle state, and printing a lot of these messages on FreeBSD 11.1:
```
Nov 01 17:52:43.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:52:44.000 [warn] S...I spotted version 0.3.1.8 consuming 100% CPU in idle state, and printing a lot of these messages on FreeBSD 11.1:
```
Nov 01 17:52:43.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:52:44.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:52:45.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:52:52.000 [warn] microdesc_cache_clean: Bug: Microdescriptor seemed very old (last listed 168 hours ago vs 168 hour cutoff), but is still marked as being held by 1 node(s). I found 1 node(s) holding it. Current networkstatus is 16 hours old. Hashtable badness is 0. (on Tor 0.3.1.8 ad5027f7dc790624)
Nov 01 17:52:52.000 [warn] microdesc_cache_clean: Bug: [0]: ID=8FCA94A1BEFA3F6E9524280528D43C1F8058327B. md=0x3073520, rs=0x428b0b0, ri=0x0. Microdesc digest in RS matches. RS okay in networkstatus. (on Tor 0.3.1.8 ad5027f7dc790624)
Nov 01 17:52:52.000 [warn] microdesc_cache_clean: Bug: Microdescriptor seemed very old (last listed 168 hours ago vs 168 hour cutoff), but is still marked as being held by 1 node(s). I found 1 node(s) holding it. Current networkstatus is 16 hours old. Hashtable badness is 0. (on Tor 0.3.1.8 ad5027f7dc790624)
Nov 01 17:52:52.000 [warn] microdesc_cache_clean: Bug: [0]: ID=A6AB9CCA65C4EAF7E9CD5EB8C53BEB77CF4743B9. md=0x2b9b9a0, rs=0x43fc550, ri=0x0. Microdesc digest in RS matches. RS okay in networkstatus. (on Tor 0.3.1.8 ad5027f7dc790624)
Nov 01 17:53:31.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:53:31.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:53:32.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:53:33.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:55:16.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:55:17.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:55:24.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [1005770 similar message(s) suppressed in last 600 seconds]
Nov 01 17:56:11.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:56:27.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:58:02.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
Nov 01 17:58:04.000 [warn] Socks version -125 not recognized. (Tor is not an http proxy.)
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24099tor should remove empty/invalid consensus cache files (Unable to map file fro...2020-06-13T15:16:42ZAlex Xutor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)I use XFS, which tends to leave newly-written files empty on crash rather than non-existent. tor should handle this better.I use XFS, which tends to leave newly-written files empty on crash rather than non-existent. tor should handle this better.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24086consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->ent...2020-06-13T15:18:36Zcypherpunksconsdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failedfound this in the logs (maybe the system was just running out of memory)
```
tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed. (on Tor 0.3.2.2-alpha )
...found this in the logs (maybe the system was just running out of memory)
```
tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed. (on Tor 0.3.2.2-alpha )
Bug: Non-fatal assertion !(ent->entry == NULL) failed in consdiffmgr_find_diff_from at ../src/or/consdiffmgr.c:637. Stack trace: (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(log_backtrace+0x44) [0x55f6dd5a54d4] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55f6dd5c0619] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(consdiffmgr_find_diff_from+0x20d) [0x55f6dd53cb9d] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x135793) [0x55f6dd557793] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(connection_dir_process_inbuf+0x721) [0x55f6dd552651] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x10aa0e) [0x55f6dd52ca0e] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x50dae) [0x55f6dd472dae] (on Tor 0.3.2.2-alpha )
Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fd9b60b95a0] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(do_main_loop+0x29d) [0x55f6dd473ead] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(tor_main+0x1c25) [0x55f6dd4779b5] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(main+0x19) [0x55f6dd46f649] (on Tor 0.3.2.2-alpha )
Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fd9b4b1b2b1] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(_start+0x2a) [0x55f6dd46f69a] (on Tor 0.3.2.2-alpha )
tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed. (on Tor 0.3.2.2-alpha )
Bug: Non-fatal assertion !(ent->entry == NULL) failed in consdiffmgr_find_diff_from at ../src/or/consdiffmgr.c:637. Stack trace: (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(log_backtrace+0x44) [0x55f6dd5a54d4] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55f6dd5c0619] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(consdiffmgr_find_diff_from+0x20d) [0x55f6dd53cb9d] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x135793) [0x55f6dd557793] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(connection_dir_process_inbuf+0x721) [0x55f6dd552651] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x10aa0e) [0x55f6dd52ca0e] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(+0x50dae) [0x55f6dd472dae] (on Tor 0.3.2.2-alpha )
Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fd9b60b95a0] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(do_main_loop+0x29d) [0x55f6dd473ead] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(tor_main+0x1c25) [0x55f6dd4779b5] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(main+0x19) [0x55f6dd46f649] (on Tor 0.3.2.2-alpha )
Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fd9b4b1b2b1] (on Tor 0.3.2.2-alpha )
Bug: /usr/bin/tor(_start+0x2a) [0x55f6dd46f69a] (on Tor 0.3.2.2-alpha )
Error from LZMA encoder: Unable to allocate memory (5).
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23985If less than 15 missing mds, Tor will delay md download for 10 mins2020-06-13T15:16:15ZGeorge KadianakisIf less than 15 missing mds, Tor will delay md download for 10 minsIn `launch_descriptor_downloads()` if we are missing between 1 to 15 mds (`MAX_DL_TO_DELAY`), Tor will delay the md download for 10 mins (or until we are missing >= 16 mds). See `TestingClientMaxIntervalWithoutRequest` for the 10 min del...In `launch_descriptor_downloads()` if we are missing between 1 to 15 mds (`MAX_DL_TO_DELAY`), Tor will delay the md download for 10 mins (or until we are missing >= 16 mds). See `TestingClientMaxIntervalWithoutRequest` for the 10 min delay.
This is bad when comboed with #21969 since if one of the 15 missing mds is for one of your top two primary guards, tor will hang for 10 mins with `missing descriptor for primary guards` before bootstrapping.
The probability of this happening is small (about 0.004 I think for 6.4k mds in total) but given the amount of clients we have this is bound to happen for some of them.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23908write_http_status_line(): Bug: status line too long. (on Tor 0.3.1.7 )2020-06-13T15:16:05Zmicahmicah@torproject.orgwrite_http_status_line(): Bug: status line too long. (on Tor 0.3.1.7 )This line seems to happen quite frequently on directory authorities who are running 0.3.1.7. Unsure if it happens to others too.This line seems to happen quite frequently on directory authorities who are running 0.3.1.7. Unsure if it happens to others too.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23862Tor only updates guard state after a consensus if it has enough directory info2020-06-13T15:15:52ZteorTor only updates guard state after a consensus if it has enough directory infoSteps to reproduce:
1. Launch tor in a fresh data directory
```
export DATADIR=`mktemp -d`
src/or/tor DataDirectory "$DATADIR" StrictNodes 1 EntryNodes 1390DFDB5603AB5A16564505D7AE8647B1818A3C
```
2. Delete its microdescriptors
```
rm -v...Steps to reproduce:
1. Launch tor in a fresh data directory
```
export DATADIR=`mktemp -d`
src/or/tor DataDirectory "$DATADIR" StrictNodes 1 EntryNodes 1390DFDB5603AB5A16564505D7AE8647B1818A3C
```
2. Delete its microdescriptors
```
rm -v "$DATADIR"/cached-microdescs*
```
3. Repeat step 1
Expected behaviour:
Tor uses the selected EntryNode
Actual Behaviour:
Tor uses a fallback directory mirror
This happens because tor should update guard state after every consensus, but it only updates guard state when it has enough directory info.
It is pathological when combined with #23817, when tor gets in a state when it doesn't have enough directory info because its guards are broken, and never updates its guard state, so it can't get enough directory info.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/23817Tor re-tries directory mirrors that it knows are missing microdescriptors2020-06-13T15:15:29ZteorTor re-tries directory mirrors that it knows are missing microdescriptorsWhen a microdescriptor for a relay changes, it takes a while to propagate to directory mirrors. In this time, a client can:
1. Download a consensus that references the new microdescriptor
2. Try a directory mirror that has an older conse...When a microdescriptor for a relay changes, it takes a while to propagate to directory mirrors. In this time, a client can:
1. Download a consensus that references the new microdescriptor
2. Try a directory mirror that has an older consensus, and therefore doesn't have that microdescriptor
3. Repeat 2
This is a particular issue when:
* the client first bootstraps, and the fallback or authority provides a newer consensus than any of its directory mirrors
* the client has been asleep for a while, and its consensus has expired, so it fetches one straight away
* only 1/3 of a client's directory guards has the new consensus
We can fix this by:
* making clients try the same directory mirror for their consensus and microdescriptors
* making clients avoid directory mirrors with missing microdescriptors
* making clients use a fallback when all of their directory mirrors don't have a microdescriptor
This issue affects primary guards and v3 onion services.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23622Maybe use "has authenticated" rather than "has authenticated as a known relay...2020-06-13T15:14:32ZNick MathewsonMaybe use "has authenticated" rather than "has authenticated as a known relay" to set client flagIn #22805, teor proposes that we should use the following rule for setting our "is this a client flag" on a channel:
>If a connecting peer has a zero identity digest, it's a client/bridge, if it doesn't, it's a relay. (A listening peer ...In #22805, teor proposes that we should use the following rule for setting our "is this a client flag" on a channel:
>If a connecting peer has a zero identity digest, it's a client/bridge, if it doesn't, it's a relay. (A listening peer is always a relay. Interestingly, bridges look like relays to clients, but look like clients to public relays.)Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23608Some channelpadidng tests still use unmocked time2020-06-13T15:14:27ZMike PerrySome channelpadidng tests still use unmocked timeI missed a couple tests in my rush to get the patch done for the merge window. Embarrassing. Patch to follow shortly.I missed a couple tests in my rush to get the patch done for the merge window. Embarrassing. Patch to follow shortly.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/23584tor-0.3.1.7/src/or/torcert.c:396: bad expression ?2020-06-13T15:14:16ZTractor-0.3.1.7/src/or/torcert.c:396: bad expression ?tor-0.3.1.7/src/or/torcert.c:396]: (style) int result is assigned to long variable.
Source code is
const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
const uint64_t expiration_time = expiration_date * 3600;
Mul...tor-0.3.1.7/src/or/torcert.c:396]: (style) int result is assigned to long variable.
Source code is
const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
const uint64_t expiration_time = expiration_date * 3600;
Multiplying something by 3600 doesn't change its type. Suggest new code
const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
const uint64_t expiration_time = expiration_date * 3600UL;
**Trac**:
**Username**: dcb314@hotmail.comTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23568[PATCH] fix format issues in zstd code on 32 bit2020-06-13T15:14:06ZTrac[PATCH] fix format issues in zstd code on 32 bitWarnings/errors when building 0.3.1.7 on 32 bit, introduced in 380736d (tor-0.3.1.1-alpha)
```
[ 103s] src/common/compress_zstd.c: In function 'tor_zstd_get_version_str':
[ 103s] src/common/compress_zstd.c:65:19: error: format '%lu' ex...Warnings/errors when building 0.3.1.7 on 32 bit, introduced in 380736d (tor-0.3.1.1-alpha)
```
[ 103s] src/common/compress_zstd.c: In function 'tor_zstd_get_version_str':
[ 103s] src/common/compress_zstd.c:65:19: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Werror=format=]
[ 103s] "%lu.%lu.%lu",
[ 103s] ~~^
[ 103s] %u
[ 103s] version_number / 10000 % 100,
[ 103s] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 103s] src/common/compress_zstd.c:65:23: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Werror=format=]
[ 103s] "%lu.%lu.%lu",
[ 103s] ~~^
[ 103s] %u
[ 103s] src/common/compress_zstd.c:67:16:
[ 103s] version_number / 100 % 100,
[ 103s] ~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 103s] src/common/compress_zstd.c:65:27: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t {aka unsigned int}' [-Werror=format=]
[ 103s] "%lu.%lu.%lu",
[ 103s] ~~^
[ 103s] %u
[ 103s] src/common/compress_zstd.c:68:16:
[ 103s] version_number % 100);
[ 103s] ~~~~~~~~~~~~~~~~~~~~`
```
%zu should be used here.
Tested on i586, x86_64, ppc, ppc64, aarch64, armv7. All on GNU gcc 7.2.1 on openSUSE.
**Trac**:
**Username**: andreasstiegerTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23551src/common/compress.c:576: tor_compress_process: Non-fatal assertion2020-06-13T15:14:00Zcypherpunkssrc/common/compress.c:576: tor_compress_process: Non-fatal assertionduplicate of #22719 ?
OS: HardenedBSD
```
Bootstrapped 100%: Done
Performing bandwidth self-test...done.
tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len ...duplicate of #22719 ?
OS: HardenedBSD
```
Bootstrapped 100%: Done
Performing bandwidth self-test...done.
tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at src/common/compress.c:576. Stack trace: (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103e31d87 <log_backtrace+0x37> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103e488a1 <tor_bug_occurred_+0x131> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
\Bug: 0xe103e4dc7b <tor_compress_process+0xcb> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103e4d32c <tor_compress+0x21c> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103e4d7e8 <tor_uncompress+0x28> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103df4c88 <connection_dir_reached_eof+0x818> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103df448d <connection_dir_reached_eof+0x1d> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103dce0b8 <connection_handle_read+0xbb8> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103d19dd1 <connection_add_impl+0x1f1> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0x36578fda06f <event_base_assert_ok_nolock_+0xc9f> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0x36578fd5f4e <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103d1b834 <do_main_loop+0x594> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103d1dcdb <tor_main+0xcb> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103d19b99 <main+0x9> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
Bug: 0xe103d089f0 <_start+0x180> at /usr/local/bin/tor (on Tor 0.3.1.5-alpha 83389502ee631465)
```Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23533Repair bug in geoip/rephist reporting from relays that only download microdes...2020-06-13T15:20:42ZNick MathewsonRepair bug in geoip/rephist reporting from relays that only download microdescriptors.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23291unintentional undefined behaviore in test-memwipe.c2020-06-13T15:12:53ZNick Mathewsonunintentional undefined behaviore in test-memwipe.cWhile working on #22839, snoek found a bug in test-memwipe.c:
>The last test, test_memwipe, segfaulted. This only happened with Rust built in. It turns out this was caused by the uninitialized buf in check_heap_buffer being smaller than...While working on #22839, snoek found a bug in test-memwipe.c:
>The last test, test_memwipe, segfaulted. This only happened with Rust built in. It turns out this was caused by the uninitialized buf in check_heap_buffer being smaller than the mem addresses being scanned. I know we're doing some dirty stuff there, but I don't think trying to read past the length of the buffer was intended. At least to me it seems fair enough for the program to segfault. I put in the obvious fix, which might be horribly wrong.
It looks fine to me, so I'm going to give it a bug number and backport it.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23275Consensus diffs are generated even if DirCache and DirPort are 02020-06-13T15:12:49ZteorConsensus diffs are generated even if DirCache and DirPort are 0I'm running tor master 257f50b22 with DirCache 0 and DirPort 0.
Every hour or so, it uses all the CPUs on my machine to create consensus diffs.
This is a waste of CPU and disk space.I'm running tor master 257f50b22 with DirCache 0 and DirPort 0.
Every hour or so, it uses all the CPUs on my machine to create consensus diffs.
This is a waste of CPU and disk space.Tor: 0.3.1.x-finalNick MathewsonNick Mathewson