The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-07T19:36:44Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2179Stream fairness: Stop packaging inbufs onto circuits greedily2022-02-07T19:36:44ZNick MathewsonStream fairness: Stop packaging inbufs onto circuits greedilyAnalysis copied from a comment in bug legacy/trac#1298, with ~~crossouts~~ and _changes_
Grepping: We call connection_edge_package_raw_inbuf() in 4 places. One is the case in relay.c that we fixed in legacy/trac#1937. The other three ca...Analysis copied from a comment in bug legacy/trac#1298, with ~~crossouts~~ and _changes_
Grepping: We call connection_edge_package_raw_inbuf() in 4 places. One is the case in relay.c that we fixed in legacy/trac#1937. The other three cases have no constraint on how much we process from the stream. They are:
* (A) connection_edge_process_relay_cell_not_open(), upon receiving a RELAY_COMMAND_CONNECTED
* (B) connection_edge_process_relay_cell(), upon receiving a RELAY_COMMAND_SENDME.
* (C) The case in relay.c that we fixed with legacy/trac#1937
* (D) connection_edge_process_inbuf(), upon receiving data on an edge connection.
Case (C) is fixed. ~~Case (D) is fair~~ Case (D) _gives preference to loud streams that show up earlier, though after that it is fair since we'll just package data as it arrives, and we consider connections that we can read from in pseuodrandom or first-come-first-served order._
Case (A) and case (B) can lead to hogging the circuit temporarily, though I think it happens in a more-or-less fair way. It would be neat to make those cases less hoggish, but we have a bit of an architectural problem in the way. Right now (as you can see above) there are two circumstances when we package edge data into relay cells:
* (1) Data arrives on an edge conn, so we package as much as we can immediately.
* (2) An edge-conn becomes non-blocked (either it was blocked on its own, or its whole circuit was blocked), so we package as much data as we can (from the connection if just one was blocked, or from all the connections on a circuit if a whole circuit was blocked).
Thus, if we leave data on an edge conn inbuf temporarily without blocking the edge conn, there's currently no mechanism to make sure that it will get pulled off unless more data arrives, or unless the edge conn becomes blocked then unblocked.
We could add such a mechanism, I guess, but I'm not currently clear on how it would look.https://gitlab.torproject.org/tpo/core/tor/-/issues/2743safelogging should cover hidden service name and intro-points too2022-02-07T19:37:07ZRoger Dingledinesafelogging should cover hidden service name and intro-points tooIn log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user ...In log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user puts his $datadir on encrypted storage, and the logs aren't on encrypted storage, then the logs could be the weak link.https://gitlab.torproject.org/tpo/core/tor/-/issues/8727ServerTransportListenAddr validation should validate that transport-name is w...2022-02-07T19:38:03ZGeorge KadianakisServerTransportListenAddr validation should validate that transport-name is well-formedSomeone put in his torrc:
```
ServerTransportListenAddr obfs2,obfs3 0.0.0.0:56831 0.0.0.0:56832
```
inspired by the format of ServerTransportPlugin. Unfortunately, this is not the correct way to use ServerTransportListenAddr. The correct...Someone put in his torrc:
```
ServerTransportListenAddr obfs2,obfs3 0.0.0.0:56831 0.0.0.0:56832
```
inspired by the format of ServerTransportPlugin. Unfortunately, this is not the correct way to use ServerTransportListenAddr. The correct way is:
```
ServerTransportListenAddr obfs2 0.0.0.0:56831
ServerTransportListenAddr obfs3 0.0.0.0:56832
```
We should at least validate that the first argument of the line is a pluggable transport name (C-identifier) to avoid stuff like "obfs2,obfs3".https://gitlab.torproject.org/tpo/core/tor/-/issues/14854Document the hardlimit of HiddenServiceAuthorizeClient basic2022-02-07T19:38:03ZcypherpunksDocument the hardlimit of HiddenServiceAuthorizeClient basicI ran some tests on HiddenServiceAuthorizeClient basic auth-type and found that it stopped working when I created 49 or more clients.
I started with 10 clients and kept adding 10 more at a time. When I had 39 clients, the hidden service ...I ran some tests on HiddenServiceAuthorizeClient basic auth-type and found that it stopped working when I created 49 or more clients.
I started with 10 clients and kept adding 10 more at a time. When I had 39 clients, the hidden service worked, but when I added 10 more, the hostname and client_keys were generated as expected, but hidden service stopped working for all of the clients.
HiddenServiceDir /var/lib/tor/test_public/ # tlxnxx74fpmkw2qh.onion
HiddenServicePort 80 127.0.0.1:80
HiddenServiceAuthorizeClient basic \
tlx_cl01, \
tlx_cl02, \
tlx_cl03, \
...
tlx_cl47, \
tlx_cl48, \
tlx_cl49
According to the man page and the specs, the stealth mode doesn't work for more than 16 clients, but implied that the basic mode should work.https://gitlab.torproject.org/tpo/core/tor/-/issues/16350tor.pid should be deleted on exit in every case possible, like assert termina...2022-02-07T19:38:03Zyurivict271tor.pid should be deleted on exit in every case possible, like assert termination, and catchable signalsI had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on F...I had tor fail with assertion, printing message into log and exiting, yet it left tor.pid. It could have easily delete it, since this wasn't the non-catchable signal.
It doesn't make sense to leave tor.pid when tor exited.
0.2.6.7 on FreeBSDhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16894Check all logging output is appropriately escaped / escaped_safe_str_client2022-02-07T19:38:03ZteorCheck all logging output is appropriately escaped / escaped_safe_str_clientSecurity bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code...Security bugs like legacy/trac#16891 show up every so often, where sensitive input is logged, rather than being obscured. Similarly, client input is sometimes logged unsanitised (I fixed one of these in the directory request logging code about 9-12 months ago.)
It would be great if someone could review all the strings that are logged by Tor, and categorise them into:
* static or calculated internally: trusted, log as-is
* externally provided: unsanitised, use escaped()
* sensitive client information: use escaped_safe_str_client()
Do we want this in 0.2.7, or should we leave it until 0.2.8?https://gitlab.torproject.org/tpo/core/tor/-/issues/27299hsv3: Clarify timing sources around hsv3 code2022-02-07T19:38:03ZGeorge Kadianakishsv3: Clarify timing sources around hsv3 codeA big source of bugs and confusions (e.g. legacy/trac#26980, legacy/trac#26930) in the HSv3 code stem from the fact that it uses various timing sources to compute time periods, SRV, etc. Some parts of the code use `time(NULL)`, others us...A big source of bugs and confusions (e.g. legacy/trac#26980, legacy/trac#26930) in the HSv3 code stem from the fact that it uses various timing sources to compute time periods, SRV, etc. Some parts of the code use `time(NULL)`, others use the current consensus valid-after, and others use the voting-schedule.
The code is currently not clear in which timing source is used in each case. As an example, some functions take as input `now` but they only use it to get a live consensus to use its valid-after, but that may confuse a reader that the `now` is used as the time source (e.g. `should_rotate_descriptors()` that caused the legacy/trac#26930 confusion).
We should try to clarify and improve the function signatures around the HSv3 codebase on this regard.https://gitlab.torproject.org/tpo/core/tor/-/issues/31609Make CIRCUIT_IS_ORIGIN() look at the base magic number2022-02-07T19:38:04ZDavid Gouletdgoulet@torproject.orgMake CIRCUIT_IS_ORIGIN() look at the base magic numberCurrently, `CIRCUIT_IS_ORIGIN()` actually looks at the purpose, not the base magic number:
```
#define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
```
We should move it to look at the `magic` like `CIRCUIT_IS_ORCIRC(...Currently, `CIRCUIT_IS_ORIGIN()` actually looks at the purpose, not the base magic number:
```
#define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
```
We should move it to look at the `magic` like `CIRCUIT_IS_ORCIRC()` is doing.
The reason is because I was adding tracing events to the circuit subsystem and I kept having state transition event with a circuit global identifier of 0 which can't be because that value is set just after allocation.
But at that point, the purpose has not been set so `CIRCUIT_IS_ORIGIN()` wasn't returning true.
Furthermore, this made me discover another issue documented in legacy/trac#31608 where if we do make this change, we _must_ fix this ticket else we have a NULL deref.https://gitlab.torproject.org/tpo/core/tor/-/issues/16564WIP: Reject bridge descriptors posted to non-bridge authorities2022-02-07T19:38:32ZRoger DingledineWIP: Reject bridge descriptors posted to non-bridge authoritiesRight now if my bridge descriptor gets uploaded to the directory authorities, poof I'm now a public relay, even if I didn't mean to be.
That's not the end of the world, since I am technically offering to be a relay already, and the only...Right now if my bridge descriptor gets uploaded to the directory authorities, poof I'm now a public relay, even if I didn't mean to be.
That's not the end of the world, since I am technically offering to be a relay already, and the only difference is that I didn't opt to publish my descriptor myself.
But still it seems like we should make the choice explicit inside the descriptor.https://gitlab.torproject.org/tpo/core/tor/-/issues/19853ServerDNSAllowNonRFC953Hostnames affects clients, and AllowNonRFC953Hostnames...2022-02-07T19:38:32ZteorServerDNSAllowNonRFC953Hostnames affects clients, and AllowNonRFC953Hostnames affects serversIt looks like the code and man page entry for ServerDNSAllowNonRFC953Hostnames was copied straight from AllowNonRFC953Hostnames, which is the equivalent client option.
I think this is ok as-is, because even though both options affect bo...It looks like the code and man page entry for ServerDNSAllowNonRFC953Hostnames was copied straight from AllowNonRFC953Hostnames, which is the equivalent client option.
I think this is ok as-is, because even though both options affect both client and server, tor instances typically only run as clients or servers, not both.
However, the manual page entries could be updated to clarify that the options are synonyms, and affect both clients and exits.https://gitlab.torproject.org/tpo/core/tor/-/issues/20986Gracefully handle build configurations on systems without AsciiDoc2022-02-07T19:38:32ZcypherpunksGracefully handle build configurations on systems without AsciiDocOn systems without AsciiDoc the build configuration aborts telling users to pass `--disable-asciidoc`. This requires users to restart the build configuration which is annoying.
Instead the build configuration should handle these cases g...On systems without AsciiDoc the build configuration aborts telling users to pass `--disable-asciidoc`. This requires users to restart the build configuration which is annoying.
Instead the build configuration should handle these cases gracefully and show a message without aborting the configuration. In these cases i would also show a less verbose message and change it to something similar to systems without Python, see https://gitweb.torproject.org/tor.git/tree/configure.ac?id=4098bfa26073551fe3f525ada7fc9079a49fd4bb#n218.https://gitlab.torproject.org/tpo/core/tor/-/issues/28597Document SOCKSPolicy better2022-02-07T19:38:32ZteorDocument SOCKSPolicy betterWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPortWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPorthttps://gitlab.torproject.org/tpo/core/tor/-/issues/29134Document the max number of v3 client auths I can make2022-02-07T19:38:32ZpastlyDocument the max number of v3 client auths I can makeI'm testing out v3 onion service client auth. I couldn't find a documented maximum number of clients I can authorize for a single onion service, so I tried a really big number (400).
Full log here: https://paste.debian.net/1061430/ and ...I'm testing out v3 onion service client auth. I couldn't find a documented maximum number of clients I can authorize for a single onion service, so I tried a really big number (400).
Full log here: https://paste.debian.net/1061430/ and first bit here:
```
matt@spacecow:~/src/tor$ ./src/app/tor -f torrc-server
Jan 19 13:34:11.635 [notice] Tor 0.3.5.7 (git-9beb085c10562a25) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0j, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Jan 19 13:34:11.635 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 19 13:34:11.635 [notice] Read configuration file "/home/matt/src/tor/torrc-server".
Jan 19 13:34:11.640 [warn] Path for DataDirectory (data-server) is relative and will resolve to /home/matt/src/tor/data-server. Is this what you wanted?
Jan 19 13:34:11.640 [warn] Path for PidFile (data-server/tor.pid) is relative and will resolve to /home/matt/src/tor/data-server/tor.pid. Is this what you wanted?
Jan 19 13:34:11.640 [warn] Path for HiddenServiceDir (data-server/onion_service) is relative and will resolve to /home/matt/src/tor/data-server/onion_service. Is this what you wanted?
Jan 19 13:34:11.641 [warn] Your log may contain sensitive information - you disabled SafeLogging. Don't log unless it serves an important reason. Overwrite the log afterwards.
Jan 19 13:34:11.666 [notice] Bootstrapped 0%: Starting
Jan 19 13:34:11.948 [notice] Starting with guard context "default"
Jan 19 13:34:12.666 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jan 19 13:34:12.666 [notice] Bootstrapped 80%: Connecting to the Tor network
Jan 19 13:34:12.722 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jan 19 13:34:13.048 [notice] Bootstrapped 100%: Done
Jan 19 13:34:14.676 [warn] We just made an HS descriptor that's too big (54736).Failing.
Jan 19 13:34:14.676 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_service.c:2828: upload_descriptor_to_hsdir: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed. (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed in upload_descriptor_to_hsdir at src/feature/hs/hs_service.c:2828. Stack trace: (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47) [0x564e05c29297] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0) [0x564e05c24930] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(hs_service_run_scheduled_events+0x1d6a) [0x564e05b4c5ca] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(+0x65e71) [0x564e05aa7e71] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(+0x697e1) [0x564e05aab7e1] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f19b89755a0] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(do_main_loop+0x9d) [0x564e05aab21d] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_run_main+0x1215) [0x564e05a990a5] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_main+0x3a) [0x564e05a962ca] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(main+0x19) [0x564e05a95e49] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f19b7ac12e1] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(_start+0x2a) [0x564e05a95e9a] (on Tor 0.3.5.7 9beb085c10562a25)
```
I didn't expect to be allowed an unlimited number of client authorizations, but I do expect Tor to handle too many more gracefully.
```
matt@spacecow:~/src/tor$ cat torrc-server
DataDirectory data-server
Log notice file data-server/notice.log
Log notice stdout
PidFile data-server/tor.pid
SocksPort 0
SafeLogging 0
LogTimeGranularity 1
HiddenServiceDir data-server/onion_service
HiddenServicePort 80 11223
```
```
matt@spacecow:~/src/tor$ cat torrc-client
DataDirectory data-client
Log notice file data-client/notice.log
Log notice stdout
PidFile data-client/tor.pid
SocksPort auto
SafeLogging 0
LogTimeGranularity 1
ClientOnionAuthDir data-client/v3onionauth
```
I wrote a script to generate a ton of .auth and .auth_private files.
1. Start the server's tor with DisableNetwork set, wait for it to bootstrap, then stop it. Grab the hostname of the onion service
2. Use this script (https://paste.debian.net/1061432/) to generate a bunch of .auth and .auth_private files. For example:
```
matt@spacecow:~/src/python-snippits/src ./x25519-gen.py \
> ck7vkjy5dfk4dh564wnhqrdhmeh4qrnnkmo5tdwu4n7wickkhbzrb7yd \
> 400 \
> ~/src/tor/data-server/onion_service/authorized_clients/ \
> ~/src/tor/data-client/v3onionauth/
```
3. Then remove DisableNetwork and start the server. It produces the above buggy logshttps://gitlab.torproject.org/tpo/core/tor/-/issues/32691Image broken in 'src-ref' documentation2022-02-07T19:38:32ZoparaImage broken in 'src-ref' documentationFor example if you visit https://src-ref.docs.torproject.org/tor/dataflow.html, the "structure hierarchy for connection types" image is missing (the img tag has a 404). There are possibly other missing images as well, but I can't find th...For example if you visit https://src-ref.docs.torproject.org/tor/dataflow.html, the "structure hierarchy for connection types" image is missing (the img tag has a 404). There are possibly other missing images as well, but I can't find the markdown files to check (there were the original versions, then they were moved to the tor git repo and edited iirc, but now they're gone).
There's also another image missing on the same page, but has no <img> tag (compare the top of the https://people.torproject.org/~nickm/tor-auto/internal/02-dataflow.html and https://src-ref.docs.torproject.org/tor/dataflow.html pages). But it may have been removed on purpose.https://gitlab.torproject.org/tpo/core/tor/-/issues/6505GETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no co...2022-02-07T19:38:59ZZack WeinbergGETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no consensus availableIf there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.If there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.https://gitlab.torproject.org/tpo/core/tor/-/issues/15661Same "non-loopback address" notice is printed twice2022-02-07T19:39:00Zyurivict271Same "non-loopback address" notice is printed twiceThe following command line produces each notice twice.
This is not a big deal, but something is wrong in the code and needs to be fixed.
```
/usr/local/bin/tor --ignore-missing-torrc -f /no/file --PidFile /var/tmp/vbox-to-tor/tap7/tor....The following command line produces each notice twice.
This is not a big deal, but something is wrong in the code and needs to be fixed.
```
/usr/local/bin/tor --ignore-missing-torrc -f /no/file --PidFile /var/tmp/vbox-to-tor/tap7/tor.pid --RunAsDaemon 1 --DataDirectory /var/tmp/vbox-to-tor/tap7/data --+Log "notice file /var/tmp/vbox-to-tor/tap7/tor.log" --DNSPort 53 --DNSListenAddress 172.16.7.1 --TransPort 9030 --TransListenAddress 172.16.7.1 --SocksPort 0
```
```
Apr 12 21:38:09.478 [notice] Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and Zlib 1.2.8.
Apr 12 21:38:09.478 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 12 21:38:09.478 [notice] Configuration file "/no/file" not present, using reasonable defaults.
Apr 12 21:38:09.483 [notice] You configured a non-loopback address '172.16.7.1:53' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.483 [notice] You configured a non-loopback address '172.16.7.1:9030' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.484 [notice] You configured a non-loopback address '172.16.7.1:53' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.485 [notice] You configured a non-loopback address '172.16.7.1:9030' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.485 [notice] Opening DNS listener on 172.16.7.1:53
Apr 12 21:38:09.485 [notice] Opening Transparent pf/netfilter listener on 172.16.7.1:9030
Apr 12 21:38:09.485 [warn] Fixing permissions on directory /var/tmp/vbox-to-tor/tap7/data
```https://gitlab.torproject.org/tpo/core/tor/-/issues/28097Get the actual Windows version from Kernel32.dll2022-02-07T19:39:00ZteorGet the actual Windows version from Kernel32.dllWindows 8.1 and later pretend to be Windows 8 (legacy/trac#28096).
If we want to display the real Windows version, we can use GetFileVersionInfo() to check the version of Kernel32.dll:
https://docs.microsoft.com/en-au/windows/desktop/Sy...Windows 8.1 and later pretend to be Windows 8 (legacy/trac#28096).
If we want to display the real Windows version, we can use GetFileVersionInfo() to check the version of Kernel32.dll:
https://docs.microsoft.com/en-au/windows/desktop/SysInfo/getting-the-system-versionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29777Rate-limit "Problem bootstrapping" warnings to one every 5 seconds2022-02-07T19:39:00ZteorRate-limit "Problem bootstrapping" warnings to one every 5 secondsLet's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89...Let's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89F14723B at 212.83.154.33:8443)
```https://gitlab.torproject.org/tpo/core/tor/-/issues/16598fsync ed25519 master key files before closing them.2022-02-07T19:39:17ZNick Mathewsonfsync ed25519 master key files before closing them.Weasel says this is a good idea, and IMO it can't hurt.Weasel says this is a good idea, and IMO it can't hurt.https://gitlab.torproject.org/tpo/core/tor/-/issues/16824Emit a warning message about side channel leaks when using relays as clients2022-02-07T19:39:17ZstarlightEmit a warning message about side channel leaks when using relays as clientsAnalysis presented in bug legacy/trac#16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is reco...Analysis presented in bug legacy/trac#16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is recommended that simultaneous client and relay operation be aggressively discouraged with a new `torrc` configuration parameter to inhibit it--default value set to prevent. In addition log warnings should be generated when both client and relay functions are allowed to operate concurrently.
Correct support of simultaneous client and relay function requires segregation of the client function to a separate thread running on a different processor core than the relay function.
Correcting the current client implementation's deficit of transaction granularity is unlikely to eliminate the potential for a sophisticated advisory to detect perturbation of cell forwarding by client circuit creation activity.