Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-09-16T14:21:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33898Stop modifying addr on connections, and delete real_addr2021-09-16T14:21:51ZteorStop modifying addr on connections, and delete real_addrIn connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remo...In connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remote peer. And for some reason, we also have conn.address, a string copy of the peer's canonical address and port.
See:
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920
This is... a mess.
Here's the high-level interface I'd like to see:
* use a function to format a connection or channel addresses for loogging
* use exactly as many address and port variables as needed in connection and channel (no extras!)
* qualify each address and port variable's name with its purpose
For example, here's one possible design:
* delete addr, port, address, and real_addr
* add remote_ap, a tor_addr_port_t that is the remote address and port of the TCP connection to the remote peer
* implement connection_describe(), which:
* formats remote_ap,
* formats is_canonical (and any other useful info), and
* calls node_describe() to format the canonical IPv4 and IPv6 addresses and ports of the remote peer.
We may also need separate fields for reverse proxied addresses, see the comment at:
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
If we need separate variables or functions for channels, we can use a similar design. (But ideally, re-using as many functions and variables as possible.)
This is important for Sponsor 55: getting accurate connection information will make diagnosing bugs much easier.
Current subtasks:
* [x] #40040 Document behavior of addr/address/real_addr fields
* [x] #40041 Add "describe connection" and "describe peer" functions.
* [ ] #40042 Give `or_connection_t` "canonical addr" instead of "real addr"Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31490hs-v3: Turns out the hs_ident circuit_type is not used2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Turns out the hs_ident circuit_type is not usedI stumble upon this while investigating legacy/trac#30200. My HS debugging showed up with circuit type set to `INTRO` for a rendezvous circuit.
In, one of the most insane function we have, `circuit_get_open_circ_or_launch()`, towards th...I stumble upon this while investigating legacy/trac#30200. My HS debugging showed up with circuit type set to `INTRO` for a rendezvous circuit.
In, one of the most insane function we have, `circuit_get_open_circ_or_launch()`, towards the end, we set the HS identifier of the open circuit:
```
circ->hs_ident =
hs_ident_circuit_new(&edge_conn->hs_ident->identity_pk,
HS_IDENT_CIRCUIT_INTRO);
```
... notice, we only use INTRO type, never the RENDEZVOUS one.
Further looking at it, it appears that the `hs_ident->circuit_type` field is just pointless. Client will only set the INTRO (see code above) and the service will properly set both. But then after that, it is just never used.
I propose we either remove it or fix the client side because if we ever rely on that field, it is of today really wrong client side.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31495cannot configure bridges2021-02-25T15:32:26ZMark Smithcannot configure bridgesWhen using code from tor master (`Tor version 0.4.2.0-alpha-dev (git-d475d7c2fb3c0ed5`), I cannot configure bridges in Tor Browser. This seems to be a very recent regression, probably caused by the changes in https://gitweb.torproject.or...When using code from tor master (`Tor version 0.4.2.0-alpha-dev (git-d475d7c2fb3c0ed5`), I cannot configure bridges in Tor Browser. This seems to be a very recent regression, probably caused by the changes in https://gitweb.torproject.org/tor.git/commit/?id=d475d7c2fb3c0ed5120c50011b187f6957a4f52c
The relevant portion of the control port conversation is:
```
SETCONF UseBridges=1 Bridge="obfs4 ..."
513 Unacceptable option value: You cannot set both UseBridges and EntryNodes.
```
As far as I can tell, `EntryNodes` is not present in any of my configuration.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31509config refactor: make test-stem should pass2020-06-27T13:49:35Zteorconfig refactor: make test-stem should passStem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of legacy/trac#29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make...Stem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of legacy/trac#29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make test-stem" manually on each PR.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31516config refactor: every function table entry should be documented and unit tested2020-06-27T13:49:35Zteorconfig refactor: every function table entry should be documented and unit testedWe've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, wh...We've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, which do the thing that the function table entry is mean to do.
Edited to add:
Also, function table types should be documented with the same level of detail as regular functions. Each argument should have a type, name?, and description.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31519git-push-all.sh: shellcheck warnings2020-06-27T13:49:35ZNick Mathewsongit-push-all.sh: shellcheck warningsWe've got a bunch of shellcheck warnings here since I merged legacy/trac#29879.We've got a bunch of shellcheck warnings here since I merged legacy/trac#29879.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31524GETINFO bw-event-cache spike value(s) in it2022-06-17T17:46:34ZtoralfGETINFO bw-event-cache spike value(s) in itDiscussing with atagar an issue with the bandwidth graph of Nyx yield into the fact, that Tor reports 1 or 2 unusal high values when nyx is started. After a minute or so the effect is gone and Nyx can scale the y-axis to a reasonable val...Discussing with atagar an issue with the bandwidth graph of Nyx yield into the fact, that Tor reports 1 or 2 unusal high values when nyx is started. After a minute or so the effect is gone and Nyx can scale the y-axis to a reasonable value.
atagar found out, that there are 1 or 2 spike values in it (look for 3495411062,3952777936) of the debug out out of Nyx:
```
08/25/2019 21:18:09 [TRACE] Sent to tor: GETINFO bw-event-cache
08/25/2019 21:18:09 [TRACE] Received from tor: 250-bw-event-cache=1374134393,1426052109 20086925,20125282 21800116,21982023 21443601,21381953 21284145,21223794 20736818,20840129 20095450,20002302 20327971,20091436 18481818,18770265 20642518,20484788 17916670,17984439 21675050,21693959 21112734,20784723 19053526,19193284 19295884,19489502 21443785,21575604 21134294,21020113 24810387,24663932 21866896,22876759 22146840,22135880 21265637,21323808 20355415,20195913 22161894,22076797 23243894,23320227 22162244,22280711 20837266,20883852 21569369,21709237 19729547,19565307 19509953,19770894 20445427,20681393 21164201,22030989 23182698,23054018 22427910,22683231 24570368,24540675 23788945,23736745 24326209,24063010 23491274,23547576 24465451,24291718 23117418,23200615 22771292,22946982 23969237,23981784 23612713,23562155 23382374,23423884 20351264,20211681 21590861,21769434 21812207,21644025 23301464,23486635 23190866,23611494 25596210,25579703 23296743,23781312 24948896,24956987 25415713,25555740 26407789,26504165 25006181,25166607 3495411062,3952777936 28124111,26406950 26007090,26935060 26897763,26935089 26866687,27170833 28168859,26699345 25750280,26406950 27570110,26935089 28007323,26935089 26590862,26935089 28579673,26935089 112518425,114606735 27113917,27462685 26127629,26406921 79812696,79748989 25846716,26896706 29074858,26973472 24947719,26935089 27687620,26864938 25539933,26838674 27171107,27068897 27140138,26879337 26899976,26495460 25950990,26844241 28442790,27025937 26116568,26829132 27827545,26960905 27035490,26415775\n250 OK
```
Just a guess: The 2 affected relays have about 20 - 40 MByte/sec bw. The spike values are often above 3,000,000,000, looking like an arbitrary unsigned long int.
Whilst the severity on the Nyx graph is negligible I do wonder about the root cause.https://gitlab.torproject.org/tpo/core/tor/-/issues/31527In Tor Browser nightly, Tor fails to boostrap, hangs at 50%2021-07-09T17:22:32ZrichardIn Tor Browser nightly, Tor fails to boostrap, hangs at 50%Tor Log:
```
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not ...Tor Log:
```
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.877 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.878 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
8/26/19, 20:54:01.878 [NOTICE] Opening Socks listener on 127.0.0.1:9150
8/26/19, 20:54:01.878 [NOTICE] Opened Socks listener on 127.0.0.1:9150
8/26/19, 20:54:01.878 [NOTICE] Renaming old configuration file to "C:\Users\user\Desktop\Tor Browser GeKo Test2\Browser\TorBrowser\Data\Tor\torrc.orig.1"
8/26/19, 20:54:02.292 [NOTICE] Bootstrapped 5% (conn): Connecting to a relay
8/26/19, 20:54:02.622 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
8/26/19, 20:54:03.285 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
8/26/19, 20:54:03.579 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
8/26/19, 20:54:03.580 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
8/26/19, 20:54:03.863 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
8/26/19, 20:54:04.155 [NOTICE] Bootstrapped 30% (loading_status): Loading networkstatus consensus
8/26/19, 20:54:06.827 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
8/26/19, 20:54:07.168 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
8/26/19, 20:54:08.289 [WARN] Your configuration excludes 100% of all possible guards. That's likely to make you stand out from the rest of the world.
8/26/19, 20:54:08.289 [NOTICE] Switching to guard context "restricted" (was using "default")
8/26/19, 20:54:08.289 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
8/26/19, 20:54:08.289 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
8/26/19, 20:54:08.290 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/0, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
8/26/19, 20:54:08.807 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
8/26/19, 20:54:09.210 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths.
```Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31529config refactoring: fix redundant reset logic2020-06-27T13:49:34ZNick Mathewsonconfig refactoring: fix redundant reset logicWe have this block in our code now:
```
// XXXX This is unreachable, since a CLEAR line always has an
// XXXX empty value.
config_reset(mgr, options, mvar, use_defaults); // LCOV_EXCL_LINE
```
We should fix it by changing it...We have this block in our code now:
```
// XXXX This is unreachable, since a CLEAR line always has an
// XXXX empty value.
config_reset(mgr, options, mvar, use_defaults); // LCOV_EXCL_LINE
```
We should fix it by changing it to a nonfatal assertion.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31531Make control_event_conf_changed() take a smartlist of config_line_t2021-09-16T14:22:37ZteorMake control_event_conf_changed() take a smartlist of config_line_tcontrol_event_conf_changed() currently takes smartlist(k, v, k, v, …), which is an unexpected API.
We should change it so the keys and values are part of a config_line_t struct, and the smartlist contains config_line_t.control_event_conf_changed() currently takes smartlist(k, v, k, v, …), which is an unexpected API.
We should change it so the keys and values are part of a config_line_t struct, and the smartlist contains config_line_t.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31532Use ptrdiff_t for struct_member_t.offset, etc2020-06-27T13:49:34ZNick MathewsonUse ptrdiff_t for struct_member_t.offset, etcWe have several fields in our configuration code that use int for a struct offset:
* `struct_member_t.offset`
* `struct_magic_decl_t.magic_offset`
* `config_format_t.config_suite_offset`
These should all use ptrdiff_t instead.We have several fields in our configuration code that use int for a struct offset:
* `struct_member_t.offset`
* `struct_magic_decl_t.magic_offset`
* `config_format_t.config_suite_offset`
These should all use ptrdiff_t instead.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31541hs-v3: Client can re-pick bad intro points2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Client can re-pick bad intro pointsOk this one took me a while to figure out!
This is sorta related to legacy/trac#25882 as it is a bug that makes the client retry constantly the same intro point even though it was flagged as having an error.
Problem lies in `client_get...Ok this one took me a while to figure out!
This is sorta related to legacy/trac#25882 as it is a bug that makes the client retry constantly the same intro point even though it was flagged as having an error.
Problem lies in `client_get_random_intro()` which randomly selects an intro point from the descriptor. Sparing the detail, this is where it goes wrong:
```
ip = smartlist_get(usable_ips, idx);
smartlist_del(usable_ips, idx);
```
... and then we use `ip` to check if usable and if yes, we connect to it.
~~We can't `del()` the value from the list until we are done with the `ip` object. The `smartlist_get()` returns a pointer to location *in the list* so if we change the list order right after acquiring the reference, we are accessing bad things, possibly junk.~~
~~So basically, junk can be used, the wrong IP can be used even though it would not pass the `intro_point_is_usable()` if it was correct pointer.~~
I was able to find this using a pathological case where the HS pins its intro point to 3 specific nodes. So, even upon a restart or desc rotation, the same IPs are re-used but with different auth key.
If a client had already connected to that service and thus had those IPs in its failure cache, it will fail to eternity to connect to the service because it basically never realize it needs to refetch a new descriptor.
Even though there is a catch all with `hs_client_any_intro_points_usable()` before extending to an intro point, the problem lies with the above which can make the code NEVER pick a certain intro point so the catch all always validate to true since there is one intro point in the list that was never tried.
This is very bad for reachability, network load, but also simple "code safety". I strongly recommend backport to our maintained version >= 032.
Fortunately for us, the fix is trivial, we should only `del()` when done with the IP object.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31542Cannot connect to IPv6 addresses using Tor SOCKS2022-06-17T12:56:12ZTracCannot connect to IPv6 addresses using Tor SOCKSHere is my Tor configuration:
```
SocksPort 127.0.0.1:9050 IPv6Traffic
SocksPort [::1]:9050 IPv6Traffic
DataDirectory /run/tor_client
ControlPort unix:/run/tor_client/control
ClientUseIPv6 1
```
I'm using 0.4.1.5 on Debian 9.
IPv4 dir...Here is my Tor configuration:
```
SocksPort 127.0.0.1:9050 IPv6Traffic
SocksPort [::1]:9050 IPv6Traffic
DataDirectory /run/tor_client
ControlPort unix:/run/tor_client/control
ClientUseIPv6 1
```
I'm using 0.4.1.5 on Debian 9.
IPv4 direct addresses are fine:
```
$ curl -s -x socks5h://127.0.0.1:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
* Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (127.0.0.1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:54:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact
$ curl -s -x socks5h://[::1]:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
* Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (::1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:55:03 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact
```
IPv6 direct addresses do not work:
```
$ curl -s -x socks5h://[::1]:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
* Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0000:0000:0000:0000:0000:0000:0000:0000:0. (1)
* Closing connection 0
$ curl -s -x socks5h://127.0.0.1:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
* Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
* Closing connection 0
```
What should I test from here?
Thanks!
**Trac**:
**Username**: sega01https://gitlab.torproject.org/tpo/core/tor/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_i...During my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points()` function which showed me 4 intro points.
I haven't found out why but one feature of HS is that we launch `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and the first one to finish are picked.
It appears that more than the defined value can finish at the same time and will be picked.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31552--disable-module-dirauth broken (missing symbols)2020-06-27T13:49:32ZTrac--disable-module-dirauth broken (missing symbols)build with ./configure --disable-module-dirauth
this will fail at linking time because of missing symbols.
It used to work in 0.4.0.5 and is broken in 0.4.1.5
for example
```
make: *** [Makefile:9672: src/app/tor] Error 1
ld.lld: er...build with ./configure --disable-module-dirauth
this will fail at linking time because of missing symbols.
It used to work in 0.4.0.5 and is broken in 0.4.1.5
for example
```
make: *** [Makefile:9672: src/app/tor] Error 1
ld.lld: error: undefined symbol: dirserv_should_launch_reachability_test
>>> referenced by ld-temp.o
>>> lto.tmp:(routers_update_status_from_consensus_networkstatus)
ld.lld: error: undefined symbol: authdir_wants_to_reject_router
>>> referenced by ld-temp.o
>>> lto.tmp:(router_add_to_routerlist)
ld.lld: error: undefined symbol: dirserv_would_reject_router
>>> referenced by ld-temp.o
>>> lto.tmp:(update_consensus_router_descriptor_downloads)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
**Trac**:
**Username**: LarryBitcoinTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31559test-timers fail on maint-0.2.92020-06-27T13:49:32Zteortest-timers fail on maint-0.2.9```
FAIL: src/test/test-timers
==========================
mean difference: 183123 usec
standard deviation: 524773.950303 usec
Either your system is under ridiculous load, or the timer backend is broken.
FAIL src/test/test-timers (ex...```
FAIL: src/test/test-timers
==========================
mean difference: 183123 usec
standard deviation: 524773.950303 usec
Either your system is under ridiculous load, or the timer backend is broken.
FAIL src/test/test-timers (exit status: 1)
```
https://travis-ci.org/torproject/tor/jobs/575709059#L2759
I wonder if this is a once-off, or if we haven't backported enough timer patches to 0.2.9.
I'll re-run the job, and see what happens.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31561hs-v3: Service can keep unused intro points in its list2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can keep unused intro points in its listTor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering legacy/trac#31548 is resolved).
...Tor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering legacy/trac#31548 is resolved).
Once the circuit of the remaining intro opens, we notice that we have too many and then re-purpose the extra ones.
However, I've noticed that sometimes establishing an intro circuit timeouts during build, basically expiring due to our CBT policy. In that case, the circuit is simply close but the intro point remains in the service descriptor list.
This is bad because of legacy/trac#31548, this means an intro point can end up in the descriptor even though the service never established any circuits to it...
We simply need to callback into the HS subsystem when we are expiring an HS circuit so appropriate actions can be taken such as in this case, removing the IP from the list.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31570INTERNAL ERROR: raw assertion failed (core dump) in termux2020-07-14T22:24:17ZTracINTERNAL ERROR: raw assertion failed (core dump) in termuxSo, I have fresh install of termux in my phone no matter if i reinstall the termux tor will crash in start does anybudy can track it down ?
```
==============================================================T= 1567005970
INTERNAL ERROR:...So, I have fresh install of termux in my phone no matter if i reinstall the termux tor will crash in start does anybudy can track it down ?
```
==============================================================T= 1567005970
INTERNAL ERROR: Raw assertion failed at /home/builder/.termux-build/tor/src/src/lib/malloc/map_anon.c:213: nodump_result == 0Aborted (core dumped)
```
Additional information:
https://github.com/termux/termux-packages/issues/4235
https://tor.stackexchange.com/questions/20222/internal-error-raw-assertion
**Trac**:
**Username**: foremtehanTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31571Add the tor version and a newline to raw_assert()2020-07-14T22:24:18ZteorAdd the tor version and a newline to raw_assert()We're missing a newline and the tor version in the logs for legacy/trac#31570.We're missing a newline and the tor version in the logs for legacy/trac#31570.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31576Remove/stop shipping contrib/dist/rc.subr2020-06-27T13:49:31ZteorRemove/stop shipping contrib/dist/rc.subrIt appears FreeBSD no longer needs it.It appears FreeBSD no longer needs it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31577make distcheck on macOS ignores --disable-asciidoc in its second configure in...2020-06-27T13:49:31Zteormake distcheck on macOS ignores --disable-asciidoc in its second configure invocationI build tor on macos using:
```
git clone https://git.torproject.org/tor.git
cd tor
mkdir build-c
../configure --disable-asciidoc --with-libevent-dir=/usr/local --with-openssl-dir=/usr/local/opt/openssl --enable-lzma --enable-zstd --enab...I build tor on macos using:
```
git clone https://git.torproject.org/tor.git
cd tor
mkdir build-c
../configure --disable-asciidoc --with-libevent-dir=/usr/local --with-openssl-dir=/usr/local/opt/openssl --enable-lzma --enable-zstd --enable-libscrypt CC=clang --enable-gcc-warnings --enable-expensive-hardening
make distcheck
```
Which fails with:
```
checking whether the compiler accepts @warning_flags... yes
==================================
Building Tor has failed since manpages cannot be built.
You need asciidoc installed to be able to build the manpages.
To build without manpages, use the --disable-asciidoc argument
when calling configure.
==================================
make: *** [distcheck] Error 1
Exit 2
```
What am I doing wrong?
Does "make distcheck" support a build directory inside tor/ ?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31578practracker scans build directories inside the tor/ directory2020-06-27T13:49:31Zteorpractracker scans build directories inside the tor/ directoryWhen I run practracker after the failed "make distcheck" in legacy/trac#31577, I get these errors:
```
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_encode() 352
problem function-size /b...When I run practracker after the failed "make distcheck" in legacy/trac#31577, I get these errors:
```
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_encode() 352
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_parse_into() 332
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks5_client_request_encode() 113
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks5_server_reply_encode() 113
problem file-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.h 995
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/hs/cell_introduce1.c:trn_cell_introduce_encrypted_encode() 110
(warning) problem file-size /src/core/or/circuitpadding.c 3096
(warning) problem function-size /src/core/or/circuitpadding.c:circpad_machine_schedule_padding() 113
(warning) problem file-size /src/core/or/circuitpadding.h 813
(warning) problem file-size /src/core/or/relay.c 3264
(warning) problem file-size /src/feature/hs/hs_service.c 4125
(warning) problem file-size /src/feature/nodelist/routerlist.c 3241
(warning) problem function-size /src/feature/rend/rendmid.c:rend_mid_establish_intro_legacy() 105
(warning) problem file-size /src/feature/rend/rendservice.c 4522
(warning) problem function-size /src/feature/rend/rendservice.c:rend_service_receive_introduction() 334
FAILURE: practracker found 482 new problem(s) in the code: see warnings above.
Please fix the problems if you can, and update the exceptions file
(../scripts/maint/practracker/./exceptions.txt) if you can't.
See doc/HACKING/HelpfulTools.md for more information on using practracker.
You can disable this message by setting the TOR_DISABLE_PRACTRACKER environment
variable.
make[1]: *** [check-best-practices] Error 226
make[1]: *** Waiting for unfinished jobs....
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31579Space out the arguments to the cell functions in rend_process_relay_cell()2020-06-27T13:49:31ZNeel Chauhanneel@neelc.orgSpace out the arguments to the cell functions in rend_process_relay_cell()In the `switch (command) {` statement in `rend_process_relay_cell()`, arguments to the functions corresponding to cells aren't spaced, like:
```
r = hs_intro_received_establish_intro(or_circ,payload,length);
```In the `switch (command) {` statement in `rend_process_relay_cell()`, arguments to the functions corresponding to cells aren't spaced, like:
```
r = hs_intro_received_establish_intro(or_circ,payload,length);
```Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31589hs-v3: Simplify decrypt_desc_layer interface2021-09-16T14:22:37ZGeorge Kadianakishs-v3: Simplify decrypt_desc_layer interfaceHere is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypt...Here is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypted_blob_size,
NULL, 1, &superencrypted_plaintext);
```
```
encrypted_len = decrypt_desc_layer(desc,
desc->superencrypted_data.encrypted_blob,
desc->superencrypted_data.encrypted_blob_size,
descriptor_cookie, 0, &encrypted_plaintext);
```
There is no point in passing `desc->superencrypted_data.encrypted_blob` and `desc->superencrypted_data.encrypted_blob_size` since we are already passing the whole `desc` and `is_superencrypted_layer` which should be enough to figure out which fields to use.
We could either of the following two things:
- Ditch `desc` as an argument and pass `desc->plaintext_data.blinded_pubkey` explicitly.
- Ditch `encrypted_blob` and `encrypted_blob_size` as arguments and get them off desc.
I prefer the first, but I'm fine with either, since it will make the interface cleaner.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31594Close all the log fds before aborting2020-07-14T22:24:28ZteorClose all the log fds before abortingWe should close the sigsafe_log_fds before abort(), so that we are less likely to lose log lines in the fd buffers.
Here are the abort() users:
* tor_abort_()
* crash_handler()
* format_number_sigsafe()
* raw_assert()
* raw_assert_unrea...We should close the sigsafe_log_fds before abort(), so that we are less likely to lose log lines in the fd buffers.
Here are the abort() users:
* tor_abort_()
* crash_handler()
* format_number_sigsafe()
* raw_assert()
* raw_assert_unreached_msg()
* trunnel_abort()
We could:
* define a raw_abort() function that closes the fds
* use it instead of abort()
* #define trunnel_abort() as raw_abort()
* update our C linter to require raw_abort() instead of abort()Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31608circuit_state_publish() never triggers when a new origin circuit is created2022-06-17T13:10:18ZDavid Gouletdgoulet@torproject.orgcircuit_state_publish() never triggers when a new origin circuit is createdIn `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit b...In `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit because `CIRCUIT_IS_ORIGIN()` doesn't return true.
Which in turn, by chance I believe, made this NULL deref on `build_state` to never happen.
This should be fixed regardless.https://gitlab.torproject.org/tpo/core/tor/-/issues/31611Work out why chutney didn't fail due to #31495 cannot configure bridges2020-06-27T13:49:30ZteorWork out why chutney didn't fail due to #31495 cannot configure bridgesIn legacy/trac#31495, Tor Browser failed, but our chutney CI job did not fail. Let's work out why that happened.In legacy/trac#31495, Tor Browser failed, but our chutney CI job did not fail. Let's work out why that happened.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31612Update the function comment in format_number_sigsafe()2021-07-22T16:19:25ZteorUpdate the function comment in format_number_sigsafe()The function comment refers to a calling function that doesn't exist any more. Now, multiple functions call format_number_sigsafe().The function comment refers to a calling function that doesn't exist any more. Now, multiple functions call format_number_sigsafe().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31613Avoid a race condition where log and err both try to close the sigsafe fds2020-06-27T13:49:30ZteorAvoid a race condition where log and err both try to close the sigsafe fdsPart of legacy/trac#31594.
I think we might want a separate ticket and changes file for this.Part of legacy/trac#31594.
I think we might want a separate ticket and changes file for this.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31614Implement clean_up_backtrace_handler()2020-07-14T22:24:28ZteorImplement clean_up_backtrace_handler()Split off legacy/trac#31594:
clean_up_backtrace_handler() doesn't do anything, but it should:
* disable backtrace signal handlers
* destroy the backtrace mutex (regression to legacy/trac#21788)Split off legacy/trac#31594:
clean_up_backtrace_handler() doesn't do anything, but it should:
* disable backtrace signal handlers
* destroy the backtrace mutex (regression to legacy/trac#21788)Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31615Reorder the early subsystems based on their dependencies2020-07-14T22:24:29ZteorReorder the early subsystems based on their dependenciesSome of our subsystem dependencies are out of sync with their module dependencies.
So if these early subsystems log, we might not be able to see the errors. (Or the process might crash.)Some of our subsystem dependencies are out of sync with their module dependencies.
So if these early subsystems log, we might not be able to see the errors. (Or the process might crash.)Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31619Describe prop220 certs in tor-spec.txt2020-06-27T13:49:29ZGeorge KadianakisDescribe prop220 certs in tor-spec.txtIIUC the ed25519 certs described in prop220 are not anywhere in tor-spec.txt even tho they are used as part of the protocol (and also as part of onion services). Shouldn't they be somewhere in torspec?IIUC the ed25519 certs described in prop220 are not anywhere in tor-spec.txt even tho they are used as part of the protocol (and also as part of onion services). Shouldn't they be somewhere in torspec?Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31624Explain config_type_extended usage and purpose2021-07-22T16:19:25ZNick MathewsonExplain config_type_extended usage and purposeFrom legacy/trac#31494, previously from legacy/trac#30914:
> Make sure that we have a good explanation of CONFIG_TYPE_EXTENDED, how it is used, and how it relates to the type_def pointer.From legacy/trac#31494, previously from legacy/trac#30914:
> Make sure that we have a good explanation of CONFIG_TYPE_EXTENDED, how it is used, and how it relates to the type_def pointer.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31625config refactoring: fix hierarchy of configuration variable flags2020-06-27T13:49:29ZNick Mathewsonconfig refactoring: fix hierarchy of configuration variable flagsFrom legacy/trac#31494, previously from comments on legacy/trac#30935:
> * Convert the "contained" flag to something more like "NOCOPY NOCHECK NODUMP".
> * at the higher level, split "contained" into "derived" and "obsolete". At the lo...From legacy/trac#31494, previously from comments on legacy/trac#30935:
> * Convert the "contained" flag to something more like "NOCOPY NOCHECK NODUMP".
> * at the higher level, split "contained" into "derived" and "obsolete". At the lower level, give both "derived" and "obsolete" the flags "NOCOPY NOCHECK NODUMP".
> * even though these concepts may have the same flags right now, we don't want to lock them in to having the same flags in future. Because they are separate concepts that are quite different. For example, "derived" has a (derived) value, but "obsolete" has no value.
> * Make the "invisible" flag more like "NODUMP NOREAD".
> * Make sure that all low-level flags are orthogonal.
> * Make sure that "invisible" vs "hidden" is more clear.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31627Fill in all missing documentation in config, confparse, etc.2020-06-27T13:49:28ZNick MathewsonFill in all missing documentation in config, confparse, etc.There are a few undocumented or underdocumented items in lib/config, lib/confmgt, and confparse.[ch]. I should fill in documentation for them before proceeding.There are a few undocumented or underdocumented items in lib/config, lib/confmgt, and confparse.[ch]. I should fill in documentation for them before proceeding.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31643Apparently NumEntryGuards is not considered if we add it after we already hav...2020-06-27T13:49:27Zs7rApparently NumEntryGuards is not considered if we add it after we already have a state file that indicates otherwiseIf we set `NumEntryGuards = 3` in torrc tor will use 3 entry guards for circuits.
After running like this, if we change the torrc parameter to `NumEntryGuards = 2` and reload Tor, it will still use 3 entry guards that were sampled befor...If we set `NumEntryGuards = 3` in torrc tor will use 3 entry guards for circuits.
After running like this, if we change the torrc parameter to `NumEntryGuards = 2` and reload Tor, it will still use 3 entry guards that were sampled before and existent in the state file.
I don't know what is our best way to treat this:
- when `NumEntryGuards` and/or `NumPrimaryGuards` changes value, delete the state file and start with a fresh one? This is a simple fix, but not the best one.
- when `NumEntryGuards` and/or `NumPrimaryGuards` changes its value (I can only see this use case when it changes the value to a lower number, not a higher one), check in the state file the last used entry guard(s) and remove from the primary list the difference of guards.https://gitlab.torproject.org/tpo/core/tor/-/issues/31644NumPrimaryGuards is set to 6, but the log file keep reports that is missing d...2020-06-27T13:49:27Zs7rNumPrimaryGuards is set to 6, but the log file keep reports that is missing descriptors for 1/3 of our primary entry guardsA Tor instance running with `NumPrimaryGuards = 6` and `NumEntryGuards = 2` will report:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of o...A Tor instance running with `NumPrimaryGuards = 6` and `NumEntryGuards = 2` will report:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We expect to run with 6 primary entry guards and use 2/6 of them all the time, so it should complain about missing descriptors for 1/6 or our primary entry guards. Or maybe this param is not processed correctly and updated in the state file.
When `NumPrimaryGuards` changes its value, we should sample more guards as primary in the existent state file, or create one if it doesn't exist with the right number of primary guards.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31647Should OBSOLETE and ___invisible configuration obtions be available to GETCONF?2022-06-17T16:36:34ZNick MathewsonShould OBSOLETE and ___invisible configuration obtions be available to GETCONF?Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.https://gitlab.torproject.org/tpo/core/tor/-/issues/31652hs-v3: Service circuit retry limit should not close a valid circuit2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service circuit retry limit should not close a valid circuitContext: Lets say a service has 3 intro circuits opened and stable.
Now, imagine one circuit collapses, like for instance the intro point restarted "tor" after an update. Our code is designed to retry 3 times that is once every second a...Context: Lets say a service has 3 intro circuits opened and stable.
Now, imagine one circuit collapses, like for instance the intro point restarted "tor" after an update. Our code is designed to retry 3 times that is once every second and then give up on the intro point.
What it looks like:
Every second, `run_build_circuit_event()` is run and launches intro circuit(s) if we are missing any. For each IP, it will increment the `circuit_retries` counter but does not actually look at it to decide to launch or not.
Before that event, also every 1 second, `cleanup_intro_points()` checks that every intro point has not expired, fell off the consensus or that `circuit_retries` is greater than (>) `MAX_INTRO_POINT_CIRCUIT_RETRIES = 3`.
Putting this together, imagine now that the first 3 attempts failed for whatever reasons and then we launch a 4th one because `circuit_retries = 3`, it does pass validation of `> MAX_INTRO_POINT_CIRCUIT_RETRIES` so then a circuit is launched and that very one succeeds.
Because `circuit_retries` is now 4 then the next second, `cleanup_intro_points()` removes the IP and closes the valid open established circuit...
I've observed the above a surprising amount of time because booting a tor relay takes some seconds mostly due to the diff-cache parsing.
In a nutshell, we should NOT launch a circuit if we reached the max retries for an intro point. This back and forth of opening a circuit and then deciding that we went over the limit makes no sense in the first place.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31657Rephrase "missing descriptors" notice log to be less confusing2020-07-14T22:24:06ZteorRephrase "missing descriptors" notice log to be less confusingSome operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total micro...Some operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We should rephrase them or document that:
* tor tries to keep active 3 primary guards for anonymity and safety
* we'll try to get new microdescs soon
* tor usually recovers quickly from this issueTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31669Invalid signature for service descriptor signing key: expired2021-06-23T17:24:15ZTracInvalid signature for service descriptor signing key: expiredwhen searching for this log entry: legacy/trac#26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not ...when searching for this log entry: legacy/trac#26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any service degradation.
```
Invalid signature for service descriptor signing key: expired
```
**Trac**:
**Username**: a_pTor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/31673Deprecated use of <sys/sysctl.h>2020-06-27T13:49:26ZDavid Gouletdgoulet@torproject.orgDeprecated use of <sys/sysctl.h>I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header ...I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header is deprecated and will be removed."
```
It is annoying with `enable-gcc-warnings` since it errors.
I've removed that include and tor builds fine so, as nickm suggested on IRC, right solution here is to not include on Linux/Win32 instead of `#ifdef HAVE_SYS_SYSCTL_H`.
I would recommend a backport since if this becomes a problem to build tor in the future.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31677Add usage help option to git scripts2020-06-27T13:49:25ZteorAdd usage help option to git scriptsThis is a follow-up to a bunch of sponsor 31 tooling changes.
While it's nice to have docs at the start of the script, it's even nicer to have a usage option "-h" and usage advice on errors.This is a follow-up to a bunch of sponsor 31 tooling changes.
While it's nice to have docs at the start of the script, it's even nicer to have a usage option "-h" and usage advice on errors.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31679Make checkShellScripts.sh handle path errors better2020-06-27T13:49:25ZteorMake checkShellScripts.sh handle path errors bettercheckShellScripts.sh has two minor bugs:
* it should handle being called from its parent directory on systems without realpath
* it should exit with an error status if it can't find the src directory
This is a fix on master, so it doesn...checkShellScripts.sh has two minor bugs:
* it should handle being called from its parent directory on systems without realpath
* it should exit with an error status if it can't find the src directory
This is a fix on master, so it doesn't need a changes file.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31682CID 1453653: Integer handling (NEGATIVE_RETURNS) in build_establish_intro_dos...2021-06-23T17:23:05ZteorCID 1453653: Integer handling (NEGATIVE_RETURNS) in build_establish_intro_dos_extension()trn_cell_extension_dos_encoded_len() returns ssize_t, but trn_cell_extension_field_setlen_field() takes size_t.
This looks like a bug on legacy/trac#30924, copying sponsor fields across.
```
/src/feature/hs/hs_cell.c: 532 in build_estab...trn_cell_extension_dos_encoded_len() returns ssize_t, but trn_cell_extension_field_setlen_field() takes size_t.
This looks like a bug on legacy/trac#30924, copying sponsor fields across.
```
/src/feature/hs/hs_cell.c: 532 in build_establish_intro_dos_extension()
528 /* Set the field with the encoded DoS extension. */
529 dos_ext_encoded_len = trn_cell_extension_dos_encoded_len(dos_ext);
530 /* Set length field and the field array size length. */
531 trn_cell_extension_field_set_field_len(field, dos_ext_encoded_len);
CID 1453653: Integer handling issues (NEGATIVE_RETURNS)
"dos_ext_encoded_len" is passed to a parameter that cannot be negative.
532 trn_cell_extension_field_setlen_field(field, dos_ext_encoded_len);
533 /* Encode the DoS extension into the cell extension field. */
534 field_array = trn_cell_extension_field_getarray_field(field);
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31683md: Bad family line in cached-microdescs.new2022-06-17T18:35:10ZDavid Gouletdgoulet@torproject.orgmd: Bad family line in cached-microdescs.newNoticed these warnings this morning on my client (Tor version 0.4.2.0-alpha-dev (git-796a9b37ea346f41)):
```
Sep 10 07:50:22.482 [warn] Bad element "$7143512F@last-listed" while parsing a node family.
Sep 10 07:50:22.482 [warn] Bad elem...Noticed these warnings this morning on my client (Tor version 0.4.2.0-alpha-dev (git-796a9b37ea346f41)):
```
Sep 10 07:50:22.482 [warn] Bad element "$7143512F@last-listed" while parsing a node family.
Sep 10 07:50:22.482 [warn] Bad element "2019-09-09" while parsing a node family.
Sep 10 07:50:22.482 [warn] Bad element "12:46:57" while parsing a node family.
```
I'm attaching the `cached-microdescs.new` file to the ticket. See line 15641:
```
ntor-onion-key tYqPErP1c49tLfeLe+PXR9t0USyps9C8vhxBdAFC+j4=
family $7143512F@last-listed 2019-09-09 12:46:57
```
I would be very surprised that dirauth published this `^` so I'm guessing we badly wrote on disk?https://gitlab.torproject.org/tpo/core/tor/-/issues/31687FreeBSD compilation warns with Tor 0.4.1.52020-07-14T22:24:14ZNick MathewsonFreeBSD compilation warns with Tor 0.4.1.5On tor-dev, grarpamp reports:
```
src/core/or/connection_edge.c:2563:5: warning: potential null pointer
dereference [-Wnull-dereference]
src/lib/math/fp.c:106:16: warning: conversion from 'double' to 'float'
may change value [-Wfloat-co...On tor-dev, grarpamp reports:
```
src/core/or/connection_edge.c:2563:5: warning: potential null pointer
dereference [-Wnull-dereference]
src/lib/math/fp.c:106:16: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
src/lib/math/fp.c:111:18: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
src/lib/math/fp.c:136:16: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
src/lib/math/fp.c:88:13: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
```Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31696Assertion failure in map-anon.c:2182020-07-14T22:24:21ZGeorg KoppenAssertion failure in map-anon.c:218We got a bug report for tor 0.4.1.5 on x86_64 14.2 Slackware system on the blog (https://blog.torproject.org/comment/283980#comment-283980):
```
Raw assertion failed at src/lib/malloc/map_anon.c:218:
noinherit_result == tor-browser_en-US...We got a bug report for tor 0.4.1.5 on x86_64 14.2 Slackware system on the blog (https://blog.torproject.org/comment/283980#comment-283980):
```
Raw assertion failed at src/lib/malloc/map_anon.c:218:
noinherit_result == tor-browser_en-US/Browser/TorBrowser/Tor/tor(dump_stack_symbols_to_error_fds+0x33)
[0x55ff75f58743] tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_raw_assertion_failed_msg_+0x86)
[0x55ff75f58e26] tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_mmap_anonymous+0xca)
[0x55ff75f57f3a] tor-browser_en-US/Browser/TorBrowser/Tor/tor(crypto_fast_rng_new_from_seed+0x35)
[0x55ff75f009f5] tor-browser_en-US/Browser/TorBrowser/Tor/tor(crypto_fast_rng_new+0x2b)
[0x55ff75f00a9b] tor-browser_en-US/Browser/TorBrowser/Tor/tor(get_thread_fast_rng+0x45)
[0x55ff75f00c35] tor-browser_en-US/Browser/TorBrowser/Tor/tor(circuit_reset_sendme_randomness+0x21)[0x55ff75e02fb1] tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x8342b)
[0x55ff75dd142b] tor-browser_en-US/Browser/TorBrowser/Tor/tor(origin_circuit_new+0x8f)
[0x55ff75dd3aef] tor-browser_en-US/Browser/TorBrowser/Tor/tor(origin_circuit_init+0x22)
[0x55ff75dcceb2] tor-browser_en-US/Browser/TorBrowser/Tor/tor(circuit_establish_circuit+0x37)[0x55ff75dcf877] tor-browser_en-US/Browser/TorBrowser/Tor/tor(circuit_launch_by_extend_info+0x9c)[0x55ff75de6b2c] tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x99859)
[0x55ff75de7859] tor-browser_en-US/Browser/TorBrowser/Tor/tor(connection_ap_handshake_attach_circuit+0x321)
[0x55ff75de8251] tor-browser_en-US/Browser/TorBrowser/Tor/tor(connection_ap_attach_pending+0x1b0)[0x55ff75dec6b0] ./TorBrowser/Tor/libevent-2.1.so.6(+0x22395)
[0x7fdac04cc395] ./TorBrowser/Tor/libevent-2.1.so.6(event_base_loop+0x55f)
[0x7fdac04ccc6f] tor-browser_en-US/Browser/TorBrowser/Tor/tor(do_main_loop+0xe5)
[0x55ff75dbce95] tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_run_main+0x1225)
[0x55ff75daa8d5] tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_main+0x3a)
[0x55ff75da7d5a] tor-browser_en-US/Browser/TorBrowser/Tor/tor(main+0x19)
[0x55ff75da78b9] /lib64/libc.so.6(__libc_start_main+0xf0)
[0x7fdabf6497d0] tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x59909)
[0x55ff75da7909]
```
0.4.0.5 worked fine on that system.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31707Better handling and UX for missing and expired guard descriptors2022-06-16T19:40:07ZteorBetter handling and UX for missing and expired guard descriptorsSplit off legacy/trac#31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
...Split off legacy/trac#31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunately, I don't think that's the kind of message that occurs multiple times, looking at legacy/trac#30746 (and friends) this seems to be able to cause havoc with just a single repeatition.
I'm not sure why this is the case, since `router_have_minimum_dir_info()` seems to be called all the time and that should eventually call `entry_guards_get_err_str_if_dir_info_missing()` which is the source of the log message... Things are kinda messy between these two functions tho, so it's kinda hard to understand what's the issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/31734Add accessor functions for cb_buf, which enforce locking and unlocking2020-07-14T22:24:25ZteorAdd accessor functions for cb_buf, which enforce locking and unlockingPart of legacy/trac#31614Part of legacy/trac#31614Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31735Exit and join all threads, before destroying any mutexes in the main thread2022-06-17T17:38:26ZteorExit and join all threads, before destroying any mutexes in the main threadOtherwise, the mutex could be locked by another thread, and destroying a locked mutex triggers undefined behaviour.
~~Part of legacy/trac#31614.~~
Updated to add:
Instead of exiting and joining threads, we can initialize the mutex onc...Otherwise, the mutex could be locked by another thread, and destroying a locked mutex triggers undefined behaviour.
~~Part of legacy/trac#31614.~~
Updated to add:
Instead of exiting and joining threads, we can initialize the mutex once, and never destroy it. If we use a sentinel value, like log_mutex_initialized, then we won't re-initialize the mutex when we re-initialize everything else.https://gitlab.torproject.org/tpo/core/tor/-/issues/31736Stop using mutex_destroy(), when multiple threads can still access the mutex2020-07-14T22:24:26ZteorStop using mutex_destroy(), when multiple threads can still access the mutexPart of legacy/trac#31614, alternative to legacy/trac#31735.
If we can't join all the threads before destroying a mutex (legacy/trac#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (B...Part of legacy/trac#31614, alternative to legacy/trac#31735.
If we can't join all the threads before destroying a mutex (legacy/trac#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (Because destroying a locked thread invokes undefined behaviour.)
There may be some other pattern that helps us destroy all but one mutex. But that involves a "mutex-destruction" mutex. Which is terribly complex.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31754Add HS DoS defence stats to heartbeat2022-10-11T23:39:34ZGeorge KadianakisAdd HS DoS defence stats to heartbeatWe should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (legacy/trac#24962)
- How many times we ...We should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (legacy/trac#24962)
- How many times we applied rate-limiting as an introduction point (legacy/trac#15516).
(Marking this as easy since the heartbeat module is not too hard to figure out)Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31757test_parseconf.sh: apparently not reliable on Appveyor2022-06-17T16:18:40ZNick Mathewsontest_parseconf.sh: apparently not reliable on AppveyorFor some reason, I'm seeing intermittent failure from test_parseconf on appveyor. Since we're close to a release, I think that for now I should make this test become allowed-to-fail on windows for now, and investigate it more after 0.4....For some reason, I'm seeing intermittent failure from test_parseconf on appveyor. Since we're close to a release, I think that for now I should make this test become allowed-to-fail on windows for now, and investigate it more after 0.4.2.1-alpha is released.https://gitlab.torproject.org/tpo/core/tor/-/issues/31759Make "annotate_ifdef_directives" script comply with line-width limits2020-06-27T13:49:22ZNick MathewsonMake "annotate_ifdef_directives" script comply with line-width limitsRight now, our annotate_ifdef_directives script generates output that is wider than 80 columns. This is okay for now, when we're applying it by hand, but won't be okay in the long run, when we eventually want to have autostyle run befor...Right now, our annotate_ifdef_directives script generates output that is wider than 80 columns. This is okay for now, when we're applying it by hand, but won't be okay in the long run, when we eventually want to have autostyle run before every commit.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31766INTERNAL_ERROR in map_anon.c2020-06-27T13:49:22ZTracINTERNAL_ERROR in map_anon.cThe following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information...The following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information, or do any testing, to resolve this.
Please see attached file "tor-0.4.1.5-fault-output.txt" for full fault output.
----------------------------------
INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:213: nodump_result == 0/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x2af1bc71bda3]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x91)[0x2af1bc71c6a1]
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/tpo/core/tor/-/issues/31769-Wextra-semi causes build failure on debian bullseye2020-06-27T13:49:22ZNick Mathewson-Wextra-semi causes build failure on debian bullseyeFrom jenkins: https://jenkins.torproject.org/job/tor-ci-linux-master/ARCHITECTURE=amd64,SUITE=bullseye/4153/consoleFull
```
09:00:39 cc1: warning: command line option '-Wextra-semi' is valid for C++/ObjC++ but not for C
```
The logical...From jenkins: https://jenkins.torproject.org/job/tor-ci-linux-master/ARCHITECTURE=amd64,SUITE=bullseye/4153/consoleFull
```
09:00:39 cc1: warning: command line option '-Wextra-semi' is valid for C++/ObjC++ but not for C
```
The logical solution here is to remove the flag.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31772MAPADDRESS control command2020-06-27T13:49:21ZTracMAPADDRESS control commandI'm using the control socket to execute MAPADDRESS commands.
Since TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the behavior changed.
On TorBrowser 8.5.4 (Linux64) with Tor 0.4.0.5 the following command worked:
MAPADDRESS *.torproject.o...I'm using the control socket to execute MAPADDRESS commands.
Since TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the behavior changed.
On TorBrowser 8.5.4 (Linux64) with Tor 0.4.0.5 the following command worked:
MAPADDRESS *.torproject.org=127.0.0.1
250 *.torproject.org=127.0.0.1
On TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the following happens:
MAPADDRESS *.torproject.org=127.0.0.1
512 syntax error: not enough arguments to mapaddress.
However, I found out that the following works:
MAPADDRESS foo *.torproject.org=127.0.0.1
250 *.torproject.org=127.0.0.1
I could not find any information about a change in the MAPADDRESS command specification.
Did the MAPADDRESS command change or may this be a bug in the command parsing?
**Trac**:
**Username**: kowenkiTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31779annotate_ifdef_directives: avoid double-negation2020-06-27T13:49:21ZNick Mathewsonannotate_ifdef_directives: avoid double-negationAs a minor tweak, we should try to stop emitting things like:
```
#else /* !(!defined(HAVE_SYS_UN_H)) */
```As a minor tweak, we should try to stop emitting things like:
```
#else /* !(!defined(HAVE_SYS_UN_H)) */
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31793Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:4...2020-07-14T22:24:05ZRoger DingledineBug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of type 0Starting tor from git master on moria1, I get tens of thousands of these:
```
Sep 18 16:32:03.546 [warn] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of ty...Starting tor from git master on moria1, I get tens of thousands of these:
```
Sep 18 16:32:03.546 [warn] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of type 0 (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] tor_bug_occurred_(): Bug: src/lib/net/address.c:318: tor_addr_is_internal_: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: Tor 0.4.2.1-alpha-dev (git-d6d3e829dd20b78e): Line unexpectedly reached at tor_addr_is_internal_ at src/lib/net/address.c:318. Stack trace: (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(log_backtrace_impl+0x47) [0x55b51002c057] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_bug_occurred_+0x19b) [0x55b5100270eb] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_addr_is_internal_+0xbf) [0x55b51001c47f] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(authdir_wants_to_reject_router+0x159) [0x55b50ff8a609] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(router_add_to_routerlist+0x50e) [0x55b50ff4a32e] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(dirserv_add_descriptor+0x239) [0x55b50ff89709] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(init_keys+0x446) [0x55b50ff5de66] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(set_options+0x755) [0x55b50ff9aae5] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(options_init_from_string+0x35a) [0x55b50ffa01ea] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(options_init_from_torrc+0x5e8) [0x55b50ffa0858] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_init+0x309) [0x55b50fe6cf99] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_run_main+0xa9) [0x55b50fe6d739] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_main+0x43) [0x55b50fe6a9c3] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(main+0x19) [0x55b50fe6a649] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0x100) [0x7fec1801dd20] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(+0x5f559) [0x55b50fe6a559] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
```Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31795Vanguard('apt install vangaurd' one) bug report2020-07-29T13:20:27ZcypherpunksVanguard('apt install vangaurd' one) bug reportHey your github is hostile against me tor user so i post it here instead!
1 Bug about bandguard.
When I set a disconnection limit to 10MB,
The client can download(GET request) a file over my onion.
But the client can not tranfer file...Hey your github is hostile against me tor user so i post it here instead!
1 Bug about bandguard.
When I set a disconnection limit to 10MB,
The client can download(GET request) a file over my onion.
But the client can not tranfer file over SSH over onion(11MB).
Can you add an ignore switch like "ignore_sshovertor_traffic_bandguard"
or
"watch_only_specific_onionname = 'hostedonion02.onion'"?https://gitlab.torproject.org/tpo/core/tor/-/issues/31796practracker git hook warning: Unusual pattern permitted.h in testdata2020-06-27T13:49:20Zteorpractracker git hook warning: Unusual pattern permitted.h in testdataWhen I go to commit code, I see:
```
Unusual pattern permitted.h in /Users/hyper/dev/tor/scripts/maint/practracker/testdata
```
I think this warning is new, but it doesn't seem right.When I go to commit code, I see:
```
Unusual pattern permitted.h in /Users/hyper/dev/tor/scripts/maint/practracker/testdata
```
I think this warning is new, but it doesn't seem right.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31807Update outdated documentation note for "bridge-distribution"2020-07-14T22:24:11ZPhilipp Winterphw@torproject.orgUpdate outdated documentation note for "bridge-distribution"Tor's man page currently documents the `BridgeDistribution` option as:
```
BridgeDistribution string
If set along with BridgeRelay, Tor will include a new line in its bridge descriptor which indicates to the BridgeDB se...Tor's man page currently documents the `BridgeDistribution` option as:
```
BridgeDistribution string
If set along with BridgeRelay, Tor will include a new line in its bridge descriptor which indicates to the BridgeDB service how it would
like its bridge address to be given out. Set it to "none" if you want BridgeDB to avoid distributing your bridge address, or "any" to let
BridgeDB decide. (Default: any)
Note: as of Oct 2017, the BridgeDB part of this option is not yet implemented. Until BridgeDB is updated to obey this option, your bridge
will make this request, but it will not (yet) be obeyed.
```
Similarly, dir-spec.txt says about `bridge-distribution-request`:
```
All bridges SHOULD include this line. Non-bridges MUST NOT include
it. (It is currently ignored by Bridge DB.)
```
BridgeDB however implements this option since 0.5.0, see legacy/trac#23957. I'll push a fix for these issues in a second.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31810Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line...2020-06-27T13:49:19ZTracBug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting.I am on Debian Buster, x86_64, trying to run Tor (installed from deb.torproject.org).
```
Sep 20 00:18:33 jennis Tor[1481]: Tor 0.4.1.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzst...I am on Debian Buster, x86_64, trying to run Tor (installed from deb.torproject.org).
```
Sep 20 00:18:33 jennis Tor[1481]: Tor 0.4.1.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Sep 20 00:18:33 jennis Tor[1481]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 20 00:18:33 jennis Tor[1481]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 20 00:18:33 jennis Tor[1481]: Read configuration file "/etc/tor/torrc".
Sep 20 00:18:33 jennis Tor[1481]: Opening Socks listener on 127.0.0.1:9050
Sep 20 00:18:33 jennis Tor[1481]: Opened Socks listener on 127.0.0.1:9050
Sep 20 00:18:33 jennis Tor[1481]: Opening DNS listener on 127.0.0.1:53
Sep 20 00:18:33 jennis Tor[1481]: Opened DNS listener on 127.0.0.1:53
Sep 20 00:18:33 jennis Tor[1481]: Opening DNS listener on [::1]:53
Sep 20 00:18:33 jennis Tor[1481]: Opened DNS listener on [::1]:53
Sep 20 00:18:33 jennis Tor[1481]: Opening Transparent pf/netfilter listener on 127.0.0.1:9040
Sep 20 00:18:33 jennis Tor[1481]: Opened Transparent pf/netfilter listener on 127.0.0.1:9040
Sep 20 00:18:33 jennis Tor[1481]: Opening Transparent pf/netfilter listener on [::1]:9040
Sep 20 00:18:33 jennis Tor[1481]: Opened Transparent pf/netfilter listener on [::1]:9040
Sep 20 00:18:33 jennis Tor[1481]: Opening Control listener on 127.0.0.1:9051
Sep 20 00:18:33 jennis Tor[1481]: Opened Control listener on 127.0.0.1:9051
Sep 20 00:18:33 jennis Tor[1481]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 20 00:18:33 jennis Tor[1482]: tor_assertion_failed_(): Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting. (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: Assertion line should be unreached failed in process_unix_exec at ../src/lib/process/process_unix.c:265: . Stack trace: (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x556988adb106] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_assertion_failed_+0x147) [0x556988ad6297] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(process_unix_exec+0x274) [0x556988ab06c4] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(process_exec+0x5b) [0x556988aaea7b] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(pt_configure_remaining_proxies+0x563) [0x5569889a0093] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(set_options+0x18ba) [0x556988a5405a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(options_init_from_string+0x382) [0x556988a55292] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(options_init_from_torrc+0x38a) [0x556988a5581a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_init+0x3c7) [0x556988927567] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_run_main+0xb4) [0x556988927e74] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55698892638a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(main+0x19) [0x556988925f49] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f49509c609b] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(_start+0x2a) [0x556988925f9a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1481]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 20 00:18:33 jennis Tor[1481]: Bootstrapped 0% (starting): Starting
Sep 20 00:18:33 jennis Tor[1481]: Starting with guard context "default"
Sep 20 00:18:33 jennis Tor[1481]: Signaled readiness to systemd
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 5% (conn): Connecting to a relay
Sep 20 00:18:34 jennis Tor[1481]: Opening Control listener on /run/tor/control
Sep 20 00:18:34 jennis Tor[1481]: Opened Control listener on /run/tor/control
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 10% (conn_done): Connected to a relay
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 14% (handshake): Handshaking with a relay
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Sep 20 00:18:35 jennis Tor[1481]: Bootstrapped 100% (done): Done
```
**Trac**:
**Username**: ParckwartTor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31825Use the full name of optional modules, rather than an abbreviation2020-07-14T22:24:16ZteorUse the full name of optional modules, rather than an abbreviationSome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthoritySome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthorityTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31827Tor unexpectedly exited.2020-06-27T13:49:18ZTracTor unexpectedly exited.Running Windows 10 1903. No antivirus, no firewall. Using Tor Browser 8.5.5.
Every start ends with error:
<<
Tor unexpectedly exited. This might be due to a bug in Tor itself, another program on your system, or faulty hardware. Until you...Running Windows 10 1903. No antivirus, no firewall. Using Tor Browser 8.5.5.
Every start ends with error:
<<
Tor unexpectedly exited. This might be due to a bug in Tor itself, another program on your system, or faulty hardware. Until you restart Tor, the Tor Browser will not able to reach any websites. If the problem persists, please send a copy of your Tor Log to the support team.
Restarting Tor will not cloe your browser tabs.
>>
Restarting does nothing. No logs are copied to clipboard.
**Trac**:
**Username**: arathefuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31832Coverage flapping in hs_get_responsible_hsdirs()2021-09-16T14:22:37ZteorCoverage flapping in hs_get_responsible_hsdirs()We should use the random seed to generate these values, so this line is always executed:
```
/* Getting the length of the list if no member is greater than the key we
* are looking for so start at the first element. */
if (i...We should use the random seed to generate these values, so this line is always executed:
```
/* Getting the length of the list if no member is greater than the key we
* are looking for so start at the first element. */
if (idx == smartlist_len(sorted_nodes)) {
UNCOV start = idx = 0;
}
```https://gitlab.torproject.org/tpo/core/tor/-/issues/31837Make test_rebind.py more robust2020-07-14T22:24:20ZteorMake test_rebind.py more robust* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during l...* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during legacy/trac#30901.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31838Fix a typo in the practracker usage message2020-06-27T13:49:18ZteorFix a typo in the practracker usage messageI don't think this needs a changes file?I don't think this needs a changes file?Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31841test addr/parse takes a long time on master on some machines2020-07-14T22:24:02Zteortest addr/parse takes a long time on master on some machinesA recent commit to master causes the addr/parse test to run for a few minutes on my Debian 10.1 install. The test works fine on maint-0.4.1, and on some of my older master branches.
This issue doesn't seem to affect our CI builders.
I ...A recent commit to master causes the addr/parse test to run for a few minutes on my Debian 10.1 install. The test works fine on maint-0.4.1, and on some of my older master branches.
This issue doesn't seem to affect our CI builders.
I haven't had time to bisect yet.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31850Integrate tor-guts Makefile into tor's build process2021-07-22T16:19:25ZNick MathewsonIntegrate tor-guts Makefile into tor's build processTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31852Rename doc/HACKING/design members to reflect current architectural division2021-07-22T16:19:25ZNick MathewsonRename doc/HACKING/design members to reflect current architectural divisionThe original tor-guts.git document pre-dated the source code re-organization when we divided things into src/lib/*, src/core/*, src/feature/*, and src/app/*.
We'll want to edit the documentation to correspond to reality. But before we d...The original tor-guts.git document pre-dated the source code re-organization when we divided things into src/lib/*, src/core/*, src/feature/*, and src/app/*.
We'll want to edit the documentation to correspond to reality. But before we do that, we'll want to rename and divide the modules so that they have the right names. (Git handles edits better if there are no edit/split/move conflicts.)Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31854In tests and log.c, stop using ~0 a log domain mask2020-06-27T13:49:17ZNick MathewsonIn tests and log.c, stop using ~0 a log domain maskThere are a few places in the tests where we use ~0 or ~0u to indicate a log domain mask that covers all domains. We also do this in log.c.
But back in legacy/trac#31080, we made the log_domain_mask_t into a 64-bit value, probably one ...There are a few places in the tests where we use ~0 or ~0u to indicate a log domain mask that covers all domains. We also do this in log.c.
But back in legacy/trac#31080, we made the log_domain_mask_t into a 64-bit value, probably one defined by a macro like LD_ALL_DOMAINS.
Additionally, we should _not_ use ~(uint64_t)0 for the definition of this value, since we don't want to include LD_NO_MOCK, LD_NOCB, and LD_NOFUNCNAME.
Found while looking at legacy/trac#31334; this should be done after legacy/trac#31334 is merged.
No backport needed, since we do not yet have any logging domains that use the high 32 bits of this type.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31884Define ExecuteBash in the Appveyor error block2020-07-14T22:24:01ZteorDefine ExecuteBash in the Appveyor error blockWhen Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mw...When Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mws73je9sihmfnTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31891make autostyle doesn't work when building outside the source tree2020-06-27T13:49:15ZTaylor Yumake autostyle doesn't work when building outside the source treeIt looks like `make autostyle` doesn't work correctly if building outside the source tree. (Here I'm building in a subdirectory of the source tree.)
```
$ make -k autostyle
abs_top_srcdir="/Users/tlyu/src/tor/build-norust/.." python3 ../...It looks like `make autostyle` doesn't work correctly if building outside the source tree. (Here I'm building in a subdirectory of the source tree.)
```
$ make -k autostyle
abs_top_srcdir="/Users/tlyu/src/tor/build-norust/.." python3 ../scripts/maint/update_versions.py
Traceback (most recent call last):
File "../scripts/maint/update_versions.py", line 98, in <module>
with open("configure.ac") as f:
FileNotFoundError: [Errno 2] No such file or directory: 'configure.ac'
make: *** [update-versions] Error 1
python3 scripts/maint/annotate_ifdef_directives.py ../src/lib/*/*.[ch] ../src/core/*/*.[ch] ../src/feature/*/*.[ch] ../src/app/*/*.[ch] ../src/test/*.[ch] ../src/test/*/*.[ch] ../src/tools/*.[ch]
/Users/tlyu/src/brew/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'scripts/maint/annotate_ifdef_directives.py': [Errno 2] No such file or directory
make: *** [autostyle-ifdefs] Error 2
python3 scripts/maint/rectify_include_paths.py
/Users/tlyu/src/brew/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'scripts/maint/rectify_include_paths.py': [Errno 2] No such file or directory
make: *** [rectify-includes] Error 2
make: Target `autostyle' not remade because of errors.
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31897util/map_anon_nofork test fails on SunOS2020-07-14T22:24:03ZTracutil/map_anon_nofork test fails on SunOSI get the following error on SunOS:
uname -a
SunOS oibuild 5.11 illumos-e7a617a7b6 i86pc i386 i86pc
```
....
FAIL: src/test/test
===================
util/load_win_lib: SKIPPED
util/log_mallinfo: SKIPPED
util/map_anon_nofork:
FAIL ...I get the following error on SunOS:
uname -a
SunOS oibuild 5.11 illumos-e7a617a7b6 i86pc i386 i86pc
```
....
FAIL: src/test/test
===================
util/load_win_lib: SKIPPED
util/log_mallinfo: SKIPPED
util/map_anon_nofork:
FAIL /export/home/svschmel/oi-userland/components/network/tor/tor-0.4.1.6/src/test/test_util.c:6223: assert(buf[0] OP_EQ 0xd0): -48 vs 208
[map_anon_nofork FAILED]
1/1360 TESTS FAILED. (2 skipped)
FAIL src/test/test (exit status: 1)
....
```
**Trac**:
**Username**: svschmelTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31898Occasional crash during shutdown when using Tor API2020-06-27T13:49:15ZMatthew FinkelOccasional crash during shutdown when using Tor APIThis is using a JNI wrapper.
I can probably create a test case for easier debugging. It seems like this is a race condition within the new pubsub system. I can reproduce this with an example program that configures Tor via the API and ...This is using a JNI wrapper.
I can probably create a test case for easier debugging. It seems like this is a race condition within the new pubsub system. I can reproduce this with an example program that configures Tor via the API and sends a `SIGNAL TERM` shortly after tor begins running and the control socket becomes available.
```
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f8bcc822535 in __GI_abort () at abort.c:79
#2 0x00007f8b94b01dbe in tor_raw_abort_ () at src/lib/err/torerr.c:227
#3 0x00007f8b94b016d0 in crash_handler (sig=<optimized out>, si=<optimized out>, ctx_=<optimized out>) at src/lib/err/backtrace.c:175
#4 <signal handler called>
#5 0x00007f8b94ae0ae4 in max_in_sl (sl=<optimized out>, sl=<optimized out>, dflt=0) at src/lib/dispatch/dispatch_new.c:36
#6 dispatch_new (cfg=0x7f8b64033520) at src/lib/dispatch/dispatch_new.c:121
#7 0x00007f8b94ade9ac in pubsub_builder_finalize (builder=0x7f8b64029eb0, items_out=0x7f8b94c193b8 <the_pubsub_items>) at src/lib/pubsub/pubsub_build.c:293
#8 0x00007f8b9496666c in tor_mainloop_connect_pubsub (builder=0x7f8b64029eb0) at src/core/mainloop/mainloop_pubsub.c:56
#9 0x00007f8b94952741 in pubsub_install () at src/app/main/main.c:1246
#10 tor_run_main (tor_cfg=<optimized out>) at src/app/main/main.c:1297
#11 0x00007f8b9495034c in RunMain (env=0x7f8bc4250b18, thisObj=0x7f8b9431d9b8) at src/feature/api/TorApi.cc:179
#12 0x00007f8b949502dd in Java_api_TorApi_runMain (env=0x7f8bc4250b18, thisObj=0x7f8b9431d9b8) at src/feature/api/TorApi.cc:279
#13 0x00007f8bac8d4990 in ?? ()
#14 0x00007f8bac8ce450 in ?? ()
#15 0x0000000718c7c3a8 in ?? ()
#16 0x00007f8b9431d950 in ?? ()
#17 0x0000000000000000 in ?? ()
```
Bisecting found `a8c0f4ddfe3f0a63bd499959c8d921346aa9766e is the first bad commit`.
The fault is at the first dereference (i don't know if it's `*u` or `*maxptr`). I'm guessing the memory was already freed for exit by the time this procedure is called.
```
29 static int
30 max_in_sl(const smartlist_t *sl, int dflt)
31 {
32 uint16_t *maxptr = NULL;
33 SMARTLIST_FOREACH_BEGIN(sl, uint16_t *, u) {
34 if (!maxptr)
35 maxptr = u;
36 else if (*u > *maxptr)
37 maxptr = u;
38 } SMARTLIST_FOREACH_END(u);
39
40 return maxptr ? *maxptr : dflt;
41 }
```
Tor was configured with `--Log "notice stdout" --AvoidDiskWrites 1 --SocksPort unix:${HOME}/private_tor/test_socks --DisableNetwork 0`.
This shouldn't be a common edge case, but I stumbled upon it while testing something else.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31921Wrap our Travis commands with travis_retry, to mitigate network timeouts2021-02-05T21:03:36ZteorWrap our Travis commands with travis_retry, to mitigate network timeoutsIf we see a lot of timeouts, we should start putting travis_retry before all our network commands:
https://docs.travis-ci.com/user/common-build-problems/#travis_retryIf we see a lot of timeouts, we should start putting travis_retry before all our network commands:
https://docs.travis-ci.com/user/common-build-problems/#travis_retryTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31922Recommend pkg-config when systemd fails2021-07-22T16:19:25ZteorRecommend pkg-config when systemd failsWe used to show an error like this when configure failed to find systemd:
```
configure: error: Package requirements (systemd >= 209) were not met:
No package 'systemd' found
Consider adjusting the PKG_CONFIG_PATH environment variable i...We used to show an error like this when configure failed to find systemd:
```
configure: error: Package requirements (systemd >= 209) were not met:
No package 'systemd' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables SYSTEMD209_CFLAGS and SYSTEMD209_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
```
But now we don't:
```
checking for pkg-config... no
checking for SYSTEMD... no
configure: Okay, checking for systemd a different way...
checking for SYSTEMD... no
configure: error: Explicitly requested systemd support, but systemd not found
```
This issue also affects lzma, and any other package that requires pkg-config.
In fact, lzma silently fails:
./configure --enable-lzma silently fails if pkg-config is not installed:
https://gitlab.com/eighthave/tor/pipelines/85811623Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31923Fix a typo in log.c2020-06-27T13:49:14ZteorFix a typo in log.clog_fn_() says "calling functions" not "calling function".log_fn_() says "calling functions" not "calling function".Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31939log spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf...2020-07-14T22:24:13ZTaylor Yulog spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0....Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```
(I assume the `#` in the middle of `INT_MAX` is a paste/transcription artifact, but then again it might not be.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31948CID 1454593: passing negative value to memset2020-06-27T13:49:13ZNick MathewsonCID 1454593: passing negative value to memsetCoverity says:
```
________________________________________________________________________________________________________
*** CID 1454593: Memory - illegal accesses (NO_EFFECT)
/src/test/test_util.c: 6200 in test_util_map_anon_nofor...Coverity says:
```
________________________________________________________________________________________________________
*** CID 1454593: Memory - illegal accesses (NO_EFFECT)
/src/test/test_util.c: 6200 in test_util_map_anon_nofork()
6194 int pipefd[2] = {-1, -1};
6195 unsigned inherit=0;
6196
6197 tor_munmap_anonymous(ptr, sz);
6198 ptr = tor_mmap_anonymous(sz, ANONMAP_NOINHERIT, &inherit);
6199 tt_ptr_op(ptr, OP_NE, 0);
>>> CID 1454593: Memory - illegal accesses (NO_EFFECT)
>>> Argument "-48" in "memset" loses precision in "memset(ptr, -48, sz)".
6200 memset(ptr, TEST_VALUE, sz);
6201
6202 tt_int_op(0, OP_EQ, pipe(pipefd));
6203 pid_t child = fork();
6204 if (child == 0) {
6205 /* We're in the child. */
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31958connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)-...2020-06-27T13:49:13ZDavid Gouletdgoulet@torproject.orgconnection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failedHmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NU...Hmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: Tor 0.4.2.0-alpha-dev (git-796a9b37ea346f41): Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed in connection_dir_is_anonymous at src/feature/dircommon/directory.c:229. Stack trace: (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(log_backtrace_impl+0x46) [0x56174b20aae6] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_bug_occurred_+0x16c) [0x56174b205d9c] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_is_anonymous+0x131) [0x56174b0ef421] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(directory_handle_command+0x1ef) [0x56174b19755f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_process_inbuf+0x95) [0x56174b0efb85] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_handle_read+0xa0d) [0x56174b064bfd] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(+0x6fe0e) [0x56174b069e0e] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8) [0x7f65e17278f8] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f65e172833f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(do_main_loop+0xd9) [0x56174b06b0f9] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_run_main+0x128d) [0x56174b058c8d] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_main+0x3a) [0x56174b0560ca] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(main+0x19) [0x56174b055c59] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65e09c2b97] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(_start+0x2a) [0x56174b055caa] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
```
This is recent code that reject HSDir single hop connections (legacy/trac#24964). Offending piece of code is:
```
/* Get the previous channel to learn if it is a client or relay link. */
if (BUG(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL)) {
log_info(LD_DIR, "Rejected HSDir request: no p_chan");
return false;
}
```
Not sure why this can BUG()...Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31970Address not work with Socks5Proxy2020-07-29T13:15:45ZTracAddress not work with Socks5ProxyMy config contains:
* Socks5Proxy 10.0.0.1:3270
* Address 123.117.32.196
But I got this log:
* Guessed our IP address as XXXX (source: 136.243.247.88).
Which XXXX is my proxy server ip
I'm using tor behind socks5 proxy, But I h...My config contains:
* Socks5Proxy 10.0.0.1:3270
* Address 123.117.32.196
But I got this log:
* Guessed our IP address as XXXX (source: 136.243.247.88).
Which XXXX is my proxy server ip
I'm using tor behind socks5 proxy, But I have public ip only blocked 80 and 443.
**Trac**:
**Username**: GongThttps://gitlab.torproject.org/tpo/core/tor/-/issues/31995test fail: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SEC...2021-06-23T17:23:06ZGeorge Kadianakistest fail: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDSweasel reported a test failing for debian:
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=mipsel&ver=0.4.2.1-alpha-1&stamp=1569200155&raw=0
```
hs_service/service_intro_point: [forking]
FAIL ../src/test/test_hs_service.c:694...weasel reported a test failing for debian:
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=mipsel&ver=0.4.2.1-alpha-1&stamp=1569200155&raw=0
```
hs_service/service_intro_point: [forking]
FAIL ../src/test/test_hs_service.c:694: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDS - 500): 1569262226 vs 1569262632
[service_intro_point FAILED]
```
this seems to have occured before in legacy/trac#25450 and legacy/trac#27810 and it's still unfixed :/Tor: 0.4.2.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/31999Default log file is handled inconsistently2020-06-27T13:49:12ZNick MathewsonDefault log file is handled inconsistentlyOur default logging setting is either "Log notice stdout" or "Log warn stdout" or "", depending on the command-line options. Right now, this is set in options_validate, which should not be setting anything at all. It's also set at the ...Our default logging setting is either "Log notice stdout" or "Log warn stdout" or "", depending on the command-line options. Right now, this is set in options_validate, which should not be setting anything at all. It's also set at the wrong time: defaults should be set in get_options_defaults(), so that they have the right semantics when you try to replace them or extend them.
I'll be fixing this as part of the parent ticket, but I'm making a separate entry here so we can refer to this bug in particular.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32016spec: ClientAuth option of ADD_ONION is only v22021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orgspec: ClientAuth option of ADD_ONION is only v2It should be specified in control-spec.txt. legacy/trac#30381 is the answer for client authorization v3 side.It should be specified in control-spec.txt. legacy/trac#30381 is the answer for client authorization v3 side.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32020hsv3: Client do not report failing circuit back into HS subsystem2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghsv3: Client do not report failing circuit back into HS subsystemThis is a subtask of the bigger larger problem in legacy/trac#25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup(...This is a subtask of the bigger larger problem in legacy/trac#25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup()` was intended for this as the entry point in the HS subsystem but only the service uses it.
Intro circuit failure needs to be noted in the failure cache (`hs_cache_client_intro_state_note()`).
Rendezvous circuit need to be also somehow handled. If the RP circuit keeps closing on us, we might want to stop trying maybe?
Same goes for HSDir circuit, if they close, client needs to be notified and launch a refetch.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32021hs-v3: Handle rendezvous client circuit build expire properly2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v3: Handle rendezvous client circuit build expire properlyThis is a subtask of the bigger larger problem in legacy/trac#25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case...This is a subtask of the bigger larger problem in legacy/trac#25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case CIRCUIT_PURPOSE_C_REND_READY:
/* We only want to spare a rend circ if it has been specified in
* an INTRODUCE1 cell sent to a hidden service. A circ's
* pending_final_cpath field is non-NULL iff it is a rend circ
* and we have tried to send an INTRODUCE1 cell specifying it.
* Thus, if the pending_final_cpath field *is* NULL, then we
* want to not spare it. */
if (TO_ORIGIN_CIRCUIT(victim)->build_state &&
TO_ORIGIN_CIRCUIT(victim)->build_state->pending_final_cpath ==
NULL)
break;
```
Basically, this `pending_final_cpath` is only used by v2 which means v3 is not handle in that case.
And that case is: if we want to expire a rendezvous client circuit that is ready but has been waiting for a while on the introduction circuit as in its cookie has been sent in the `INTRODUCE1`, we want to spare it until the intro point client circuit collapses.
Because v3 is not handled in the above, rendezvous circuit will be tagged as timed out with the general cutoff instead of being kept until the intro circuit is ready or times out. And we time out intro circuit being established much later than an established rendezvous circuit for which the `general_cutoff` will be applied on.
Bottom line is that we need a flag within the rendezvous client circuit (probably hs_ident_t?) that its cookie was put in the INTRO1 cell and that we are waiting on the intro side signalling the `circuit_expire_building()` that it should wait more on that circuit.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32022Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen ...2022-06-16T19:43:37ZTaylor YuBug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Following up from legacy/trac#31939, which reduces the log spamming from this assertion, we should figure out why this happens.Following up from legacy/trac#31939, which reduces the log spamming from this assertion, we should figure out why this happens.https://gitlab.torproject.org/tpo/core/tor/-/issues/32032Assertion mp->conf_state == PT_PROTO_COMPLETED failed in managed_proxy_stdout...2023-12-02T19:30:03ZDavid Fifielddcf@torproject.orgAssertion mp->conf_state == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callbackI'm using commit 0d82a8be77ae8d7fb06c8702bfbf1ebbaf370c94.
Create a fake server transport plugin called "test.sh" that only exits with an SMETHOD-ERROR. `chmod +x` it.
```
#!/bin/sh
echo "VERSION 1"
echo "SMETHOD-ERROR testpt failing AB...I'm using commit 0d82a8be77ae8d7fb06c8702bfbf1ebbaf370c94.
Create a fake server transport plugin called "test.sh" that only exits with an SMETHOD-ERROR. `chmod +x` it.
```
#!/bin/sh
echo "VERSION 1"
echo "SMETHOD-ERROR testpt failing ABCD"
```
Create a configuration file called "torrc.testpt".
```
PublishServerDescriptor 0
AssumeReachable
SOCKSPort 0
ORPort auto
ServerTransportPlugin testpt exec ./testpt.sh
Bridge testpt 127.0.0.1:9999
```
Run `tor -f torrc.testpt` and observe the following assertion failure:
```
Oct 10 15:56:22.000 [notice] Starting with guard context "default"
Oct 10 15:56:22.000 [warn] Server managed proxy encountered a method error. (testpt failing ABCD)
Oct 10 15:56:22.000 [warn] Managed proxy at './testpt.sh' failed the configuration protocol and will be destroyed.
Oct 10 15:56:22.000 [err] tor_assertion_failed_(): Bug: src/feature/client/transports.c:1836: managed_proxy_stdout_callback: Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: Tor 0.4.2.2-alpha-dev (git-0d82a8be77ae8d7f): Assertion mp->conf_state == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at src/feature/client/transports.c:1836: . Stack trace: (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(log_backtrace_impl+0x56) [0x563a200ffaa6] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(tor_assertion_failed_+0x147) [0x563a200fab27] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(+0xd7994) [0x563a1ffbf994] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(+0x1e6883) [0x563a200ce883] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f036a38e9ba] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f036a38f537] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(do_main_loop+0xdb) [0x563a1ff5c15b] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(tor_run_main+0x1105) [0x563a1ff49b15] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(tor_main+0x3a) [0x563a1ff470ca] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(main+0x19) [0x563a1ff46c89] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f0369dbb09b] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Oct 10 15:56:22.000 [err] Bug: ./src/app/tor(_start+0x2a) [0x563a1ff46cda] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)
Aborted
```
The same crash happens if you omit `VERSION 1` from testpt.sh.
```
#!/bin/sh
echo "SMETHOD-ERROR testpt failing ABCD"
```
I encountered this in practice with meek-server when it couldn't open its log file. It reports the failure to open a log file as an SMETHOD-ERROR, because in older versions of tor that was the only way to cause an error message to appear in the tor log file. In my case, the failure looked like this:
```
Oct 10 21:30:26 tor2 Tor-meek[2223]: Server managed proxy encountered a method error. (meek error opening log file: open /var/log/meek-server-meek.log: read-only file system)
Oct 10 21:30:26 tor2 Tor-meek[2223]: Managed proxy at '/usr/local/bin/meek-server' failed the configuration protocol and will be destroyed.
Oct 10 21:30:26 tor2 Tor-meek[2223]: tor_assertion_failed_(): Bug: ../src/feature/client/transports.c:1836: managed_proxy_stdout_callback: Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on Tor 0.4.1.6 )
Oct 10 21:30:26 tor2 Tor-meek[2223]: Bug: Assertion mp->conf_state == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at ../src/feature/client/transports.c:1836: . Stack trace: (on Tor 0.4.1.6 )
...
```Tor: 0.4.2.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32033process_unix_exec assertion failure when ServerTransportPlugin refers to none...2020-06-27T13:49:11ZDavid Fifielddcf@torproject.orgprocess_unix_exec assertion failure when ServerTransportPlugin refers to nonexistent fileI'm using commit 0d82a8be77ae8d7fb06c8702bfbf1ebbaf370c94.
Create a file called torrc.nonexistent:
```
PublishServerDescriptor 0
AssumeReachable
SOCKSPort 0
ORPort auto
ServerTransportPlugin nonexistent exec /usr/bin/nonexistent
Bridge...I'm using commit 0d82a8be77ae8d7fb06c8702bfbf1ebbaf370c94.
Create a file called torrc.nonexistent:
```
PublishServerDescriptor 0
AssumeReachable
SOCKSPort 0
ORPort auto
ServerTransportPlugin nonexistent exec /usr/bin/nonexistent
Bridge nonexistent 127.0.0.1:9999
```
Run `tor -f torrc.nonexistent` and observe the following assertion failure (which occurs in a subprocess and doesn't bring down the main tor process):
```
Oct 10 16:08:13.000 [notice] Starting with guard context "default"
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] tor_assertion_failed_(): Bug: src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting. (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] Bug: Tor 0.4.2.2-alpha-dev (git-0d82a8be77ae8d7f): Assertion line should be unreached failed in process_unix_exec at src/lib/process/process_unix.c:265: . Stack trace: (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] Bug: ./src/app/tor(log_backtrace_impl+0x56) [0x5568c162baa6] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] Bug: ./src/app/tor(tor_assertion_failed_+0x147) [0x5568c1626b27] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] Bug: ./src/app/tor(process_unix_exec+0x274) [0x5568c15fca24] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [notice] Unknown line received by managed proxy (Oct 10 16:08:09.000 [err] Bug: ./src/app/tor(process_exec+0x5b) [0x5568c15faddb] (on Tor 0.4.2.2-alpha-dev 0d82a8be77ae8d7f)).
Oct 10 16:08:13.000 [warn] Pluggable Transport process terminated with status code 6
```Tor: 0.4.2.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32034tor reads PT protocol messages from stderr2020-06-27T13:49:11ZDavid Fifielddcf@torproject.orgtor reads PT protocol messages from stderrCreate a fake server transport plugin that writes PT protocol strings to stderr, not stdout:
```
#!/bin/sh
(
echo "VERSION 1"
echo "SMETHOD testpt 127.0.0.1:9999"
echo "SMETHODS DONE"
) 2>&1
```
Verify that it writes nothing to stdout:...Create a fake server transport plugin that writes PT protocol strings to stderr, not stdout:
```
#!/bin/sh
(
echo "VERSION 1"
echo "SMETHOD testpt 127.0.0.1:9999"
echo "SMETHODS DONE"
) 2>&1
```
Verify that it writes nothing to stdout:
```
$ ./testpt.stderr.sh >/dev/null | wc
0 0 0
```
Run tor with this torrc:
```
PublishServerDescriptor 0
AssumeReachable
SOCKSPort 0
ORPort auto
ServerTransportPlugin testpt exec ./testpt.stderr.sh
Bridge testpt 127.0.0.1:9999
```
A log line shows that tor has interpreted PT protocol messages from stderr, when it should only be looking for them on stdout.
```
Oct 10 16:21:11.000 [notice] Registered server transport 'testpt' at '127.0.0.1:9999'
```
----
I think this is a bug. [pt-spec says](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef#n368) "All Pluggable Transport Proxies communicate to the parent process via writing NL-terminated lines to stdout." It does not say that tor should inspect stderr and interpret any lines that happen to be a well-formed PT protocol message that it finds there, as if they had been sent on stdout.
The only mention of stderr in the spec is [in the context of LOG and STATUS](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef#n599), and that is [a fairly recent addition](https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef) with legacy/trac#28179/legacy/trac#28181. I always thought that the intention was to copy anything seen on stderr to tor's log, as if it had been part of a LOG message on stdout. The mention of stderr in relation to STATUS is something I missed during review of that part of the spec, because I don't think it makes sense there.
What I expected to see was this, treating verbatim stderr lines as things to be logged:
```
[notice] Unknown line received by managed proxy (VERSION 1)
[notice] Unknown line received by managed proxy (SMETHOD testpt 127.0.0.1:9999)
[notice] Unknown line received by managed proxy (SMETHODS DONE)
```
Otherwise, tor is essentially holding transport plugins to a contract that is unstated in the spec: transport plugins cannot safely write anything to stderr at all, because there is always a danger that a future version of tor will recognize it as a PT message and interpret it, instead of just logging it.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32040HS intro padding machine reactivates after receiving INTRODUCE_ACK2021-07-15T13:41:34ZGeorge KadianakisHS intro padding machine reactivates after receiving INTRODUCE_ACKWhile reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down...While reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down. Then when INTRODUCE_ACK arrives, it reactivates (probably because INTRODUCE_ACK is part of the accepted purposes and the machine is shutdown/freed at that time) and sends again padding, then again shuts down...
This does not work as intended and causes extra cells to fly in with a pattern that probably does not help them blend in.
Here are some Tor logs (with padanalysis incoming/outgoing cells logs):
```
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:57.000 [warn] outgoing-cell: EXTEND 0
Oct 11 13:25:58.000 [warn] incoming-cell: EXTENDED 0 148
Oct 11 13:25:58.000 [warn] outgoing-cell: INTRODUCE1 4
Oct 11 13:25:58.000 [warn] outgoing-cell: PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (7)
Oct 11 13:25:58.000 [warn] incoming-cell: INTRODUCE_ACK 4 0
Oct 11 13:25:58.000 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Oct 11 13:25:58.000 [info] circpad_setup_machine_on_circ(): Registering machine client_ip_circ to origin circ 5 (8)
Oct 11 13:25:58.000 [info] circpad_node_supports_padding(): Checking padding: supported
Oct 11 13:25:58.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 5 (8), command 2
Oct 11 13:25:58.000 [warn] outgoing-cell: 8 PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [info] circpad_machine_spec_transition(): Circuit 5 circpad machine 0 transitioning from 0 to 1
Oct 11 13:25:58.000 [info] circpad_marked_circuit_for_padding(): Circuit 5 is not marked for close because of a pending padding machine in index 0.
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (15)
...
Oct 11 13:36:11.000 [info] circuit_mark_for_close_(): Circuit 4130340667 (id: 5) marked for close at src/core/or/circuituse.c:1509 (orig reason: 9, new reason: 0)
```
I'm not sure what the fix should be here. It might be that we need to remove INTRODUCE_ACK from the list of accepted purposes, but if we do that then if INTRODUCE_ACK arrives earlier we will stop padding after. Hmm.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/32048Loading a high number of Onion V3 Descriptors trough Tor Control Port lead to...2020-07-29T13:24:16ZnaifLoading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPULoading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPU.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ...Loading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPU.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1516 debian-+ 20 0 136604 122136 8880 R 100.0 6.0 95:16.49 tor
This is a GlobaLeaks system, try.globaleaks.org that have more than 1200 evaluation whistleblowing sites.
Trying profiling with strace and ltrace gives those data, if could be interesting to diagnose what's the issue:
root@scw-nostalgic-stonebraker:/var/log# strace -f -c -p 1516
strace: Process 1516 attached
strace: [ Process PID=1516 runs in x32 mode. ]
strace: [ Process PID=1516 runs in 64 bit mode. ]
^Cstrace: Process 1516 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.008475 15 560 getpid
0.00 0.000000 0 36 read
0.00 0.000000 0 22 write
0.00 0.000000 0 1 close
0.00 0.000000 0 6 ioctl
0.00 0.000000 0 7 sendto
0.00 0.000000 0 6 getsockopt
0.00 0.000000 0 1 rename
0.00 0.000000 0 2 epoll_wait
0.00 0.000000 0 14 epoll_ctl
0.00 0.000000 0 1 openat
0.00 0.000000 0 64 getrandom
------ ----------- ----------- --------- --------- ----------------
100.00 0.008475 720 total
root@scw-nostalgic-stonebraker:/var/log# ltrace -c -f -p 1516
^C% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
25.29 2.614242 127 20496 strlen
24.99 2.583754 126 20489 free
24.93 2.577376 125 20496 memset
24.70 2.553016 124 20485 strchr
0.02 0.002249 173 13 gettimeofday
0.02 0.001980 94 21 time
0.01 0.001290 86 15 __vsnprintf_chk
0.01 0.000653 130 5 pthread_mutex_lock
0.01 0.000642 128 5 pthread_mutex_unlock
0.00 0.000494 82 6 strcasecmp
0.00 0.000494 98 5 __vasprintf_chk
0.00 0.000439 87 5 pthread_getspecific
0.00 0.000423 84 5 event_active
0.00 0.000420 84 5 malloc
------ ----------- ----------- --------- --------------------
100.00 10.337472 82051 total
Tor version 0.3.5.8-1 is stock on Ubuntu Bionic .Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32058mainloop: make periodic events restartable2020-07-14T22:24:09Zteormainloop: make periodic events restartableWhen we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.When we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32059Bug when reading accounting interval while starting a new relay2022-06-22T15:27:46ZTracBug when reading accounting interval while starting a new relay```
[warn] router_should_be_dirserver(): Bug: An accounting interval is not allowed to be zero seconds long. Raising to 1. (on Tor 0.3.5.8 )
[notice] Your Tor server's identity key fingerprint is 'x'
[notice] Configured hibernation. This...```
[warn] router_should_be_dirserver(): Bug: An accounting interval is not allowed to be zero seconds long. Raising to 1. (on Tor 0.3.5.8 )
[notice] Your Tor server's identity key fingerprint is 'x'
[notice] Configured hibernation. This interval begins at 2019-09-30 00:00:00 and ends at 2019-09-30 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
[notice] Configured hibernation. This interval begins at 2019-10-14 00:00:00 and ends at 2019-10-15 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
```
To reproduce: start a new relay with following torrc
```
SocksPort 0
DataDirectory /var/lib/tor/relay3
ORPort 1234
Nickname test
AccountingMax 100 GBytes
AccountingStart day 00:00
```
**Trac**:
**Username**: willbarrhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32060CID 1454761: wrong type passed to unlock_cb_buf()?2020-07-14T22:24:11ZteorCID 1454761: wrong type passed to unlock_cb_buf()?Maybe it should be `void *cb_buf[]`
```
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
/src/lib/err/backtrace.c: 107 in unlock_cb_buf()
101 }
102
103 /** Unlock the static stack pointer buffer. */
104 static void...Maybe it should be `void *cb_buf[]`
```
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
/src/lib/err/backtrace.c: 107 in unlock_cb_buf()
101 }
102
103 /** Unlock the static stack pointer buffer. */
104 static void
105 unlock_cb_buf(void *cb_buf)
106 {
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
Passing argument "cb_buf" of type "void *" and argument "2048UL /* 256 * sizeof (void *) */" to function "memset" is suspicious.
107 memset(cb_buf, 0, SIZEOF_CB_BUF);
108 pthread_mutex_unlock(&cb_buf_mutex);
109 }
```Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32063CID 1454769: Resource leaks in build_establish_intro_dos_extension()2021-06-23T17:23:06ZteorCID 1454769: Resource leaks in build_establish_intro_dos_extension()Caused by legacy/trac#31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 ...Caused by legacy/trac#31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 TRUNNEL_DOS_PARAM_TYPE_INTRO2_BURST_PER_SEC,
528 service_config->intro_dos_burst_per_sec);
529
530 /* Set the field with the encoded DoS extension. */
531 ret = trn_cell_extension_dos_encoded_len(dos_ext);
532 if (BUG(ret <= 0)) {
CID 1454769: Resource leaks (RESOURCE_LEAK)
Variable "field" going out of scope leaks the storage it points to.
533 return -1;
534 })
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org