Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-11-14T16:59:05Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40735[WARN] Tried connecting to router ... identity keys were not as expected2023-11-14T16:59:05Zcypherpunks[WARN] Tried connecting to router ... identity keys were not as expectedBackground: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as exp...Background: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as expected: wanted *FP1* + no ed25519 key but got *FP2* + *edFP*.
```
Ideas of what happened:
* MITM
* Bridge operator reinstalled it in-between me getting the bridge and now.
What is wrong:
* Bridge should be marked as unreachable: either it is not used already and connections are doomed to spend resources for nothing, or it should not be used as something is clearly wrong with it
* There should be a way to distinguish first idea from second - my best guess is building a tunneled directory connection to bridge authority and asking "Is there a bridge *FP2* and does it listen on *address*?"https://gitlab.torproject.org/tpo/core/tor/-/issues/40686SocksPort WorldWritable sets file mode to 755 instead of 6662022-12-14T15:47:28ZJeremy Sakladjeremy@saklad5.comSocksPort WorldWritable sets file mode to 755 instead of 666### Summary
Unix domain sockets that are configured to be WorldWritable have incorrect permissions. Such sockets are unusable as a result, since write access is needed for clients to work.
### Steps to reproduce:
1. Use a configuratio...### Summary
Unix domain sockets that are configured to be WorldWritable have incorrect permissions. Such sockets are unusable as a result, since write access is needed for clients to work.
### Steps to reproduce:
1. Use a configuration file with the following options, where `/usr/local/var/run/tor` is a directory with appropriate permissions:
```
SocksPort unix:/usr/local/var/run/tor/socks-group GroupWritable RelaxDirCheck
SocksPort unix:/usr/local/var/run/tor/socks-world WorldWritable
```
2. Run the following command to view their permissions:
```sh
stat /usr/local/var/run/tor/socks-group /usr/local/var/run/tor/socks-world
```
Note that listening on two sockets is **not** necessary to reproduce this bug: it merely makes it easier to see the difference.
### What is the current bug behavior?
Sockets with WorldWritable have the wrong permissions, in contrast to the correctly-implemented GroupWritable:
```
srw-rw---- /usr/local/var/run/tor/socks-group
srwxr-xr-x /usr/local/var/run/tor/socks-world
```
### What is the expected behavior?
```
srw-rw---- /usr/local/var/run/tor/socks-group
srw-rw-rw- /usr/local/var/run/tor/socks-world
```
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
0.4.7.10
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
macOS 12.6
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
Homebrew
### Relevant logs and/or screenshots
N/A: even `Log debug` doesn't say anything beyond noting that a socket is successfully opened.
### Possible fixes
Investigate whether [this conditional statement](https://gitlab.torproject.org/tpo/core/tor/-/blob/28413e75605cc2d05a2a3e4c766bfbe0a47d848d/src/core/mainloop/connection.c#L1358-1362) is somehow causing an issue.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40677Errors parsing descriptors2022-10-31T20:42:12ZTom Rittertom@ritter.vgErrors parsing descriptors```
Sep 27 12:18:43.000 [notice] Bootstrapped 55% (loading_descriptors): Loading relay descriptors
Sep 27 12:18:43.000 [warn] Bad element "$E470DD7B0" while parsing a node family.
Sep 27 12:18:43.000 [warn] Bogus ed25519 key in microdesc...```
Sep 27 12:18:43.000 [notice] Bootstrapped 55% (loading_descriptors): Loading relay descriptors
Sep 27 12:18:43.000 [warn] Bad element "$E470DD7B0" while parsing a node family.
Sep 27 12:18:43.000 [warn] Bogus ed25519 key in microdesc
Sep 27 12:18:43.000 [warn] parse error: Malformed object: missing object end line
Sep 27 12:18:43.000 [warn] Unparseable microdescriptor found in download or generated string
Sep 27 12:18:43.000 [warn] Bad element "$B101B81F3CB7C284ADDF19CD" while parsing a node family.
Sep 27 12:18:43.000 [warn] Bad element "$AC249C56C11FDDFA9" while parsing a node family.
Sep 27 12:18:43.000 [warn] parse error: Malformed object: missing object end line
Sep 27 12:18:43.000 [warn] Unparseable microdescriptor found in download or generated string
Sep 27 12:18:43.000 [warn] Bogus ed25519 key in microdesc
Sep 27 12:18:43.000 [warn] parse error: Malformed object: missing object end line
Sep 27 12:18:43.000 [warn] Unparseable microdescriptor found in download or generated string
```
I'm running 0.4.7.8https://gitlab.torproject.org/tpo/core/tor/-/issues/40534slow/process/callbacks on Android often quits with error but no message2023-05-30T18:38:18Zeighthaveslow/process/callbacks on Android often quits with error but no messageThere is an intermittent but frequent problem when running the test on Android in GitLab CI. `test-slow` quits with an error but outputs no message:
https://gitlab.com/eighthave/tor-android/-/jobs/1905373288
```console
$ adb -e shell "...There is an intermittent but frequent problem when running the test on Android in GitLab CI. `test-slow` quits with an error but outputs no message:
https://gitlab.com/eighthave/tor-android/-/jobs/1905373288
```console
$ adb -e shell "cd /data/local/tmp; ./$f"'; echo -n $? > '"$f.result";
test-slow
external/test/x86_64/test-slow: 1 file pushed, 0 skipped. 26.3 MB/s (8254824 bytes in 0.299s)
WARNING: linker: ./test-slow: unused DT entry: type 0x6ffffef5 arg 0x8bf18
WARNING: linker: ./test-slow: unused DT entry: type 0x6ffffffe arg 0xbb56c
WARNING: linker: ./test-slow: unused DT entry: type 0x6fffffff arg 0x2
slow/crypto/s2k_rfc2440: OK
slow/crypto/s2k_pbkdf2: OK
slow/crypto/s2k_rfc2440_general: OK
slow/crypto/s2k_rfc2440_legacy: OK
slow/crypto/s2k_errors: OK
slow/crypto/scrypt_vectors: SKIPPED
slow/crypto/pbkdf2_vectors: OK
slow/crypto/pwbox: OK
slow/crypto/fuzz_donna/ed25519_donna: [forking] OK
slow/crypto/fuzz_donna/ed25519_ref10: [forking] OK
slow/process/callbacks:
$
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40507Tor's 'GETINFO ADDRESS' command always reports '551 Address unknown'2022-02-28T19:41:06ZAngie TatorTor's 'GETINFO ADDRESS' command always reports '551 Address unknown'While versions up to 0.4.4.6 behave correctly, with 0.4.5.6 up to the latest version 0.4.5.10 (from the respective [Windows Expert Bundles](https://www.torproject.org/download/tor/)) I experience that Tor's 'GETINFO ADDRESS' command no l...While versions up to 0.4.4.6 behave correctly, with 0.4.5.6 up to the latest version 0.4.5.10 (from the respective [Windows Expert Bundles](https://www.torproject.org/download/tor/)) I experience that Tor's 'GETINFO ADDRESS' command no longer works, always returning a '551 Address unknown' statement.
I use that feature on various Windows systems (7, 8, 10) with the [OmniMix TorIP](https://danner-net.de/omom/tutortorplusip.htm) module, mainly to retrieve my office's dynamic IP address from abroad through a hidden service, kind of a DDNS substitute without having to rely on a 3rd party provider.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40302ORPort incorrectly detected as non-reachable in 0.4.5.6/62022-06-24T14:33:37ZrotorORPort incorrectly detected as non-reachable in 0.4.5.6/6### Summary
After my bridge upgrade from 0.4.3.5 to 0.4.5.5 (and now 0.4.5.6 - from your "debian stable main" repository) my ORPort isn't detected as reacheable anymore (a message in logs after 20 minutes). However, when I check it with...### Summary
After my bridge upgrade from 0.4.3.5 to 0.4.5.5 (and now 0.4.5.6 - from your "debian stable main" repository) my ORPort isn't detected as reacheable anymore (a message in logs after 20 minutes). However, when I check it with telnet or even using your TCP reachability test it is completely fine. I suspect, it is a regression related to more aggressive IPv6 mode (I've seen the other issues, but they seemed to be fixed in 0.4.5.6).
I tried to set `ORPort` to "55555 IPv4Only", but it does seem to be ignored. I still observe:
> Unable to find IPv4 address for ORPort 55555. You might want to specify IPv4Only to it or set an explicit address or set Address.
maybe related to #40300.
As I run Tor in a container image in Podman, I cannot easily define an IP address in the configuration. In addition the container might support IPv6 at its network interface, but my external (host's) network does not. That might be confusing for Tor and maybe the external checker tries to reach it using IPv6.
It would be good to be able to simply disable IPv6 globally (IPv4Only in ORPort doesn't work for me). Related to #40208? Is there any workaround available right now to make it work again?
### Environment
Tor 0.4.5.6 from your "debian stable main" repository
> Tor 0.4.5.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc.https://gitlab.torproject.org/tpo/core/tor/-/issues/33375Stop advertising an IPv6 exit policy when DNS is broken for IPv62022-02-28T19:41:05ZteorStop advertising an IPv6 exit policy when DNS is broken for IPv6When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the desc...When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the descriptor, check `dns_seems_to_be_broken_for_ipv6()` before including an IPv6 exit policy
* reset `dns_seems_to_be_broken_for_ipv6()` periodically, maybe every 1-3 days?https://gitlab.torproject.org/tpo/core/tor/-/issues/33129Tor node that is not part of the consensus should not be used as rendezvous p...2022-10-24T20:53:07ZcypherpunksTor node that is not part of the consensus should not be used as rendezvous point with the onion serviceAccording to this article attacker is able to to chose a server that is running Tor but is not part of the Tor network as an rendezvous point with the onion service so that he can discover in to which family onion service`s guard node be...According to this article attacker is able to to chose a server that is running Tor but is not part of the Tor network as an rendezvous point with the onion service so that he can discover in to which family onion service`s guard node belongs and than use that information to ddos Tor nodes in that family so that onion service drops that guard node and instead chose his Tor node as a guard node.
https://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33072When under load, give 503 aggressively for dirport requests without compression2022-03-21T19:36:49ZNick MathewsonWhen under load, give 503 aggressively for dirport requests without compressionPreliminary analysis of the parent ticket suggests that most of the problematic requests are coming from an aggressively non-tor sources. One reasonable thing we could do to disfavor them is to give a 503 to directory requests that don'...Preliminary analysis of the parent ticket suggests that most of the problematic requests are coming from an aggressively non-tor sources. One reasonable thing we could do to disfavor them is to give a 503 to directory requests that don't request compression, either with a ".z" suffix or an Accept-Encoding list.https://gitlab.torproject.org/tpo/core/tor/-/issues/32729"hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating fail...2023-03-23T09:17:08Zeighthave"hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating failed tests on AndroidWhen repeated running the Android `TorService` test suite from https://gitlab.com/eighthave/tor-android, I occasionally received this crash:
```
main src/feature/hs/hs_circuitmap.c:598: hs_circuitmap_init: Assertion !the_hs_circu...When repeated running the Android `TorService` test suite from https://gitlab.com/eighthave/tor-android, I occasionally received this crash:
```
main src/feature/hs/hs_circuitmap.c:598: hs_circuitmap_init: Assertion !the_hs_circuitmap failed; aborting.
TorService Bug: Tor 0.4.2.5 (git-7e55ab23311d00b6): Assertion !the_hs_circuitmap failed in hs_circuitmap_init at src/feature/hs/hs_circuitmap.c:598: . (Stack trace not available) (on Tor 0.4.2.5 7e55ab23311d00b6)
libc Fatal signal 6 (SIGABRT), code -6 in tid 862 (tor), pid 836 (oid.binary.test)
TorService ⇠ run [1425ms]
DEBUG #00 pc 00000af0 [vdso:f319a000] (__kernel_vsyscall+16)
#01 pc 0001edf8 /system/lib/libc.so (syscall+40)
#02 pc 0001f073 /system/lib/libc.so (abort+115)
#03 pc 0025ab6e /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_raw_abort_+31)
#04 pc 0025673e /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_abort_+31)
#05 pc 0014df1d /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (hs_circuitmap_init+146)
#06 pc 00154110 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (hs_init+39)
#07 pc 000b17ac /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_init+132)
#08 pc 000b2033 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_run_main+243)
#09 pc 000b0933 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (Java_org_torproject_jni_TorService_runMain+59)
#10 pc 000085c8 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/oat/x86/base.odex (offset 0x8000)
#11 pc 000091ff [anon:libc_malloc:e6980000]
#12 pc 01114457 /dev/ashmem/dalvik-main space (region space) (deleted)
#13 pc 80e30d65 <unknown>
```
* I think this only happened if Tor quit the test before due to bad command line args
* it could be that the Android Test Orchestrator is reusing state that it shouldn't be https://developer.android.com/training/testing/junit-runner#using-android-test-orchestrator
* "The Dalvik process hosting a typical app is forked off of zygote with all the common android libraries already mapped, so new unique copies don't have to be opened" https://stackoverflow.com/questions/9153166/understanding-android-zygote-and-dalvikvm
nickm said:
> So there are at least two possibilities:
> 1) tor is busted and is calling hs_circuitmap_init() more than it should
> 2) tor is busted and is calling hs_circuitmap_free_all() less than it should there are probably more, like:
> 3) there is a problem in the android harness, and it is trying to restart tor before it has shut downTor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32340[Android] FAIL src/test/test_process_slow.c:240: assert(smartlist_len(process...2023-01-31T15:37:26Zeighthave[Android] FAIL src/test/test_process_slow.c:240: assert(smartlist_len(process_data->stdout_data) OP_EQ 12): 2 vs 12Running the _test-slow_ suite fails every time with this error on 0.4.1.x, 0.4.2.x, and master:
```
slow/process/callbacks:
FAIL src/test/test_process_slow.c:240: assert(smartlist_len(process_data->stdout_data) OP_EQ 12): 2 vs 12
[...Running the _test-slow_ suite fails every time with this error on 0.4.1.x, 0.4.2.x, and master:
```
slow/process/callbacks:
FAIL src/test/test_process_slow.c:240: assert(smartlist_len(process_data->stdout_data) OP_EQ 12): 2 vs 12
[callbacks FAILED]
```
The full build/test log is here:
https://gitlab.com/eighthave/tor/-/jobs/336701282
To try this yourself, it'll be easiest using the Guardian Project fork, which is in sync on GitHub and GitLab:
* https://github.com/guardianproject/tor
* https://gitlab.com/guardianproject/tor
I looked into it a bit, but couldn't quite figure out what was being tested there. Is it Tor's "smartlist" functions? stdin/stdout/stderr have annoying, arbitrary restrictions in Android, so it could be related to that. For example, "native" code loaded from a shared library will have stdin/stdout/stderr redirected to /dev/null, while in Java code, it is reachable. There is a related example on legacy/trac#32036https://gitlab.torproject.org/tpo/core/tor/-/issues/7707Impose a minimum write size for TLS writes2022-02-28T19:41:25ZNick MathewsonImpose a minimum write size for TLS writesReported pseudonymously:
If our TokenBucketRefillInterval is very low, we'll frequently wind up with very small writes, which can be exceptionally bad with TLS. One answer is to say "don't do that then" and keep TokenBucketRefillInterf...Reported pseudonymously:
If our TokenBucketRefillInterval is very low, we'll frequently wind up with very small writes, which can be exceptionally bad with TLS. One answer is to say "don't do that then" and keep TokenBucketRefillInterfal to about 100msec or so. Another answer is to nagle our TLS writes, and never write less than the full amount in the output buffer, or one cell, whichever is smaller.
For non-TLS writes, the kernel should nagle for us, so we're probably fine, though it might be sensible to impose a write threshold there too.