The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T18:02:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27906PrivCount noise specification2022-06-17T18:02:00ZteorPrivCount noise specificationLet's write a spec for PrivCount noise:
* how noise is determined for each statistic
* how much noise each relay adds
* how to interpret the final result
* how to avoid obvious pitfallsLet's write a spec for PrivCount noise:
* how noise is determined for each statistic
* how much noise each relay adds
* how to interpret the final result
* how to avoid obvious pitfallshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27901Build fails on FreeBSD/mips, but succeeds when auroreconf is run before the b...2020-07-28T23:10:39Zyurivict271Build fails on FreeBSD/mips, but succeeds when auroreconf is run before the buildDiscussion: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231779#c8Discussion: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231779#c8Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27900Please establish which C standard tor code complies with2020-06-27T13:52:00Zyurivict271Please establish which C standard tor code complies withCurrently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac...Currently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac:
> AX_CHECK_COMPILE_FLAG([-std=cNN], [CFLAGS="$CFLAGS -std=cNN"])
Reason#1: in FreeBSD we have several architectures some of which use different compilers (gcc/clang/etc) It is good to take guessing from the process and establish what standard the code complies with.
Reason#2: Some compilers might default to the older standard where a newer standard is required.
My guess is that the standard is c11.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27896base32 padding inconsistency between client and server in HS v3 client auth p...2022-06-22T15:22:37ZTracbase32 padding inconsistency between client and server in HS v3 client auth previewThere seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 charac...There seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 characters in length and won't work otherwise (i.e., if = signs are removed), while the client would work without the padding (i.e., = signs removed) but will ignore the client's private key if the padding is present.
I don't think this affects how the feature works (which I haven't been able to test anyway because it doesn't seem to enforce authorization at this stage - it still seems to let everyone in), but at least it seems to affect which values are valid and allowed to be loaded when reading the config.
**Trac**:
**Username**: jchevalihttps://gitlab.torproject.org/tpo/core/tor/-/issues/27893memory leak in dump_config()2020-06-27T13:52:01ZNick Mathewsonmemory leak in dump_config()I build with AddressSanitizer and run `./src/app/tor --dump-config non-builtin`. This gives me:
```
Direct leak of 39 byte(s) in 2 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7fc055a1...I build with AddressSanitizer and run `./src/app/tor --dump-config non-builtin`. This gives me:
```
Direct leak of 39 byte(s) in 2 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7fc055a14c37 in __GI___vasprintf_chk (/lib64/libc.so.6+0x10ac37)
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x7fc058855320 in strdup (/lib64/libasan.so.5+0x3b320)
#1 0x55c6f60d7780 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55c6f5f5b327 in validate_data_directories src/app/config/config.c:7856
#3 0x55c6f5f5b327 in options_validate src/app/config/config.c:3385
#4 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#5 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#6 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#7 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#8 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#9 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#10 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d3115 in smartlist_new src/lib/smartlist_core/smartlist_core.c:28
#3 0x55c6f5f6294c in options_validate_scheduler src/app/config/config.c:3239
#4 0x55c6f5f6294c in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f60d31c9 in smartlist_new src/lib/smartlist_core/smartlist_core.c:31
#4 0x55c6f5f6294c in options_validate_scheduler src/app/config/config.c:3239
#5 0x55c6f5f6294c in options_validate src/app/config/config.c:4533
#6 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#7 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#8 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#9 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#10 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#11 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#12 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f62bc3 in options_validate_scheduler src/app/config/config.c:3243
#4 0x55c6f5f62bc3 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f62a65 in options_validate_scheduler src/app/config/config.c:3251
#4 0x55c6f5f62a65 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f63318 in options_validate_scheduler src/app/config/config.c:3247
#4 0x55c6f5f63318 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
```
I think this is happening because options_validate is called from config_dump(), but config_dump() frees defaults_tmp using config_free instead of or_options_free.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27892Split the non-stats part of the stats module into different modules2021-09-16T14:28:09ZNick MathewsonSplit the non-stats part of the stats module into different modulesPart of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Part of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27879Remove pathbias code2021-09-16T14:28:09ZtraumschuleRemove pathbias codeThis is blocked by legacy/trac#26886.
mikeperry in comment:7:issue:27228:
> I think it is fine to remove all of the pathbias code once we get a tagging resistant cipher in place, such as https://gitweb.torproject.org/torspec.git/tree/pr...This is blocked by legacy/trac#26886.
mikeperry in comment:7:issue:27228:
> I think it is fine to remove all of the pathbias code once we get a tagging resistant cipher in place, such as https://gitweb.torproject.org/torspec.git/tree/proposals/295-relay-crypto-with-atl.txt
Hoping for further guidance in any case i will just try this. We'll see if i end up with a stable tor.
Once this is merged unresolved pathbias bugs become obsolete and it might make legacy/trac#16764, legacy/trac#21084, legacy/trac#25783 easier.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27869"netstatus" in core should not depend on "hibernate" in features2021-09-16T14:28:09ZNick Mathewson"netstatus" in core should not depend on "hibernate" in featuresThis ought to be an easy dependency to reverse.This ought to be an easy dependency to reverse.https://gitlab.torproject.org/tpo/core/tor/-/issues/27864Split router.c and routerkeys.c into separate modules2021-09-16T14:28:09ZNick MathewsonSplit router.c and routerkeys.c into separate modulesTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27863Bootstrap hangs when disconnected2020-06-27T13:52:01ZDamian JohnsonBootstrap hangs when disconnectedHi network team. When disconnected from the network tor bootstrapping hangs of late...
```
% cat dummy_torrc
SocksPort 0
ControlPort 9051
CookieAuthentication 1
ExitPolicy reject *:*
```
```
% tor -f dummy_torrc
Sep 25 10:45:09.631 [n...Hi network team. When disconnected from the network tor bootstrapping hangs of late...
```
% cat dummy_torrc
SocksPort 0
ControlPort 9051
CookieAuthentication 1
ExitPolicy reject *:*
```
```
% tor -f dummy_torrc
Sep 25 10:45:09.631 [notice] Tor 0.3.5.2-alpha-dev (git-7d9bea6a773cc18c) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Sep 25 10:45:09.632 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 25 10:45:09.632 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 25 10:45:09.632 [notice] Read configuration file "/home/atagar/Desktop/stem/dummy_torrc".
Sep 25 10:45:09.634 [notice] Opening Control listener on 127.0.0.1:9051
Sep 25 10:45:09.634 [notice] Opened Control listener on 127.0.0.1:9051
Sep 25 10:45:09.000 [notice] Bootstrapped 0%: Starting
Sep 25 10:45:10.000 [notice] Starting with guard context "default"
[ waited five minutes, didn't get any further ]
^CSep 25 10:50:11.000 [notice] Interrupt: exiting cleanly.
```
This is of concern to me because when Stem launches a tor instance it waits for a bootstrap message indicating success. As such, tools like tor-prompt hang when not connected to a network.
This once wasn't the case but I'm unsure when it regressed.https://gitlab.torproject.org/tpo/core/tor/-/issues/27861Tor 0.3.5.2-alpha-dev c82163dff468443d Bug in tor_assertion_failed_()2020-06-27T13:52:02ZTracTor 0.3.5.2-alpha-dev c82163dff468443d Bug in tor_assertion_failed_()Hi
Here is the log:
Sep 25 22:54:55.000 [notice] new bridge descriptor 'ahwahnee' (cached): $193423CE506EB2EE2BC119C40CCC9CA2C0B403BA~ahwahnee at 137.74.197.106
Sep 25 22:54:55.000 [debug] routerlist_retry_directory_downloads(): In rout...Hi
Here is the log:
Sep 25 22:54:55.000 [notice] new bridge descriptor 'ahwahnee' (cached): $193423CE506EB2EE2BC119C40CCC9CA2C0B403BA~ahwahnee at 137.74.197.106
Sep 25 22:54:55.000 [debug] routerlist_retry_directory_downloads(): In routerlist_retry_directory_downloads()
Sep 25 22:54:55.000 [debug] router_reset_descriptor_download_failures(): In router_reset_descriptor_download_failures()
Sep 25 22:54:55.000 [debug] networkstatus_reset_download_failures(): In networkstatus_reset_download_failures()
Sep 25 22:54:55.000 [err] tor_assertion_failed_(): Bug: src/core/mainloop/mainloop.c:1641: reschedule_directory_downloads: Assertion fetch_networkstatus_event failed; aborting. (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: Assertion fetch_networkstatus_event failed in reschedule_directory_downloads at src/core/mainloop/mainloop.c:1641. Stack trace: (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(log_backtrace_impl+0x48) [0x55c5d29aee78] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_assertion_failed_+0x97) [0x55c5d29aa347] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(reschedule_directory_downloads+0x78) [0x55c5d2820728] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(routerlist_descriptors_added+0xc4) [0x55c5d28d8bc4] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(router_load_routers_from_string+0x41a) [0x55c5d28daf5a] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(+0x1213a4) [0x55c5d28db3a4] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(router_reload_router_list+0x26) [0x55c5d28db536] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_run_main+0x1524) [0x55c5d280e594] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_main+0x3b) [0x55c5d280b62b] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(main+0x1a) [0x55c5d280b1ba] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f4331b06223] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(_start+0x2e) [0x55c5d280b21e] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
**Trac**:
**Username**: fo0xyTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27859update travis CI to ubuntu xenial image when available2021-02-05T21:03:36ZTracupdate travis CI to ubuntu xenial image when availabletrusty support ends April 2019, and xenial has [zstd](https://packages.ubuntu.com/source/xenial-updates/libzstd)
**Trac**:
**Username**: cyberpunkstrusty support ends April 2019, and xenial has [zstd](https://packages.ubuntu.com/source/xenial-updates/libzstd)
**Trac**:
**Username**: cyberpunkshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27858enable zstd on linux CI2021-09-16T14:28:09ZTracenable zstd on linux CIIt was left out of legacy/trac#27090 because the package wasn't in ubuntu trusty.
**Trac**:
**Username**: cyberpunksIt was left out of legacy/trac#27090 because the package wasn't in ubuntu trusty.
**Trac**:
**Username**: cyberpunkshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27856dh_initialized in crypto_dh_nss.c is always zero2020-06-27T13:52:02ZTracdh_initialized in crypto_dh_nss.c is always zero
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27855Tor exited during startup2020-07-28T23:08:25ZTracTor exited during startup9/25/18, 13:52:22.810 [WARN] You specified a public address '42.93.251.189:3128' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
9/...9/25/18, 13:52:22.810 [WARN] You specified a public address '42.93.251.189:3128' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
9/25/18, 13:52:22.810 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
**Trac**:
**Username**: kevinnoahTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27854Integration test(s) for tor-resolve2021-09-16T14:28:09Zrl1987Integration test(s) for tor-resolvehttps://gitlab.torproject.org/tpo/core/tor/-/issues/27853tor-resolve manpage points to doc/socks-extensions.txt2020-06-27T13:52:02Zrl1987tor-resolve manpage points to doc/socks-extensions.txt> See doc/socks-extensions.txt in the Tor package for protocol details.
We no longer have a file at this path in tor repo.> See doc/socks-extensions.txt in the Tor package for protocol details.
We no longer have a file at this path in tor repo.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/27849Bootstrapping hangs with 'SocksPort 0'2020-06-27T13:52:02ZTracBootstrapping hangs with 'SocksPort 0'Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, b...Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, but the backend onion services and our normal onion services were still working. The issue was that the tor daemon on onion.debian.org could not achieve bootstrap. tor 0.3.3.9 worked with the existing config, but 0.3.4.8 did not. Changing the SocksPort parameter from 0 to 6666 allowed tor 0.3.4.8 to achieve bootstrap.
The config does not contain any onion services, because those are setup by onionbalance via the tor control port.
So the issue appears to be that tor is not trying to contact the tor network unless it has a socks port or an onion service or other tor network requiring thing configured.
```
SocksPort 0
Log notice syslog
#HiddenServiceSingleHopMode 1
#HiddenServiceNonAnonymousMode 1
ControlPort 9051
```
**Trac**:
**Username**: pabsTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27844rerun rustfmt2020-06-27T13:52:03ZTracrerun rustfmt
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27842Consider end-to-end introduction ACKs2022-06-17T13:32:15ZGeorge KadianakisConsider end-to-end introduction ACKsRight now introduction points send an ACK back to the client without making sure that the service heard the introduction request or can act on it.
Perhaps in the future we can do end-to-end ACKs from the service to the client as a means...Right now introduction points send an ACK back to the client without making sure that the service heard the introduction request or can act on it.
Perhaps in the future we can do end-to-end ACKs from the service to the client as a means of minimizing protocol bugs and issues.