The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-12-07T20:34:52Zhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/7Identify important anti-features2023-12-07T20:34:52ZMatthew FinkelIdentify important anti-featuresIdentify features and/or functionality that the app should discourage or prevent (to the best of its ability). This will include anti-abuse mechanisms and potential "footguns" (preferring misuse resistant UI/UX/features).Identify features and/or functionality that the app should discourage or prevent (to the best of its ability). This will include anti-abuse mechanisms and potential "footguns" (preferring misuse resistant UI/UX/features).Sponsor 101 - Tor VPN Client for Android2023-12-04https://gitlab.torproject.org/tpo/ux/research/-/issues/69Test Tor VPN prototypes with potential users2024-03-26T22:46:21ZdonutsTest Tor VPN prototypes with potential usersThis ticket relates to the following objectives:
- O1.4: Test wireframes and user flows with target users, identify user challenges, iterate on these designs throughout the project.
Our target is to conduct 2-3 focus groups with potent...This ticket relates to the following objectives:
- O1.4: Test wireframes and user flows with target users, identify user challenges, iterate on these designs throughout the project.
Our target is to conduct 2-3 focus groups with potential users.
The designs can be found here: [Figma / Tor VPN for Android](https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m/Tor-VPN-for-Android?type=design&node-id=4280%3A1524&mode=design&t=mNf6BRHqG6b1oXYs-1)Sponsor 101 - Tor VPN Client for Androidsajolidasajolidahttps://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/anti-censorship/pluggable-transports/snowflake-webext/-/issues/36Lockscreen, screensaver disabled while a proxy session is active2022-09-28T21:30:47ZpromeneurLockscreen, screensaver disabled while a proxy session is activeopenSUSE 15.3
Chrome 96
snowflake 0.5.4
When someone uses snowflake and uses webrtc protocol
then
my PC lokscreen and screensaver are disabled.
It's normal if I use webrtc but not if someone uses webrtc via snowflake.openSUSE 15.3
Chrome 96
snowflake 0.5.4
When someone uses snowflake and uses webrtc protocol
then
my PC lokscreen and screensaver are disabled.
It's normal if I use webrtc but not if someone uses webrtc via snowflake.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/network-health/metrics/geoip-data/-/issues/1publish geoip JARs to Maven Central2023-12-07T20:12:53Zeighthavepublish geoip JARs to Maven CentralFor Tor Browser, Orbot, TorServices, and other Android apps that use geoip, it would be super useful to have the geoip files published to Maven Central. Its the standard place for Android and Java libraries, and accepts arbitrary packag...For Tor Browser, Orbot, TorServices, and other Android apps that use geoip, it would be super useful to have the geoip files published to Maven Central. Its the standard place for Android and Java libraries, and accepts arbitrary packages as well. It also fully supports reproducible builds with a .buildinfo file. This new generation method should also publish there. Sine this is built using a gitlab-ci job, it could also automatically publish to the local Package Registry https://gitlab.torproject.org/tpo/network-health/metrics/geoip-data/-/packages
Here's an example of how it should be deployed:
https://repo1.maven.org/maven2/info/guardianproject/geoip/20191217/
This is my code so far, I'm happy to help integrate it: [geoip-maven.zip](/uploads/31b8909ffcbedfd736e6eec881533a75/geoip-maven.zip)micahmicah@torproject.orgmicahmicah@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/chutney/-/issues/31639When Travis updates the homebrew cache in their images, stop updating it in ....2022-02-07T19:31:27ZteorWhen Travis updates the homebrew cache in their images, stop updating it in .travis.ymlIn legacy/trac#30928, we added a homebrew update to .travis.yml for shellcheck.
legacy/trac#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.In legacy/trac#30928, we added a homebrew update to .travis.yml for shellcheck.
legacy/trac#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.https://gitlab.torproject.org/tpo/core/torspec/-/issues/124Authorities should cap relay consensus weight as a new consensus method2022-07-18T17:54:03ZteorAuthorities should cap relay consensus weight as a new consensus methodarma says on IRC:
```
armadev: teor4: is there a ticket for capping the total weight a given relay can get? i remember you mentioning that this should happen as a new consensus method, i.e. so the authorities actually collectively cap it...arma says on IRC:
```
armadev: teor4: is there a ticket for capping the total weight a given relay can get? i remember you mentioning that this should happen as a new consensus method, i.e. so the authorities actually collectively cap it, rather than relying on each vote individually to do it. i think that's a compelling idea.
```
I'm not sure if the cap should be the same across the network, or if it should be different based on each relay's MaxAdvertisedBandwidth.
If we want to base it on MaxAdvertisedBandwidth, we should also make MaxAdvertisedBandwidth a separate number in relay descriptor bandwidth lines, rather than combining it with bandwidth rate and bandwidth burst.https://gitlab.torproject.org/tpo/core/torspec/-/issues/157hs: Do not allow more than one control cell on a circuit2022-10-17T19:28:01ZDavid Gouletdgoulet@torproject.orghs: Do not allow more than one control cell on a circuitThis is the list of HS control cell that is they are all for establishing a circuit or/and "connection" between HS entities (IP, RP, Service, client):
```
RELAY_COMMAND_ESTABLISH_INTRO:
RELAY_COMMAND_ESTABLISH_RENDEZVOUS:
RELAY_COMMAND_...This is the list of HS control cell that is they are all for establishing a circuit or/and "connection" between HS entities (IP, RP, Service, client):
```
RELAY_COMMAND_ESTABLISH_INTRO:
RELAY_COMMAND_ESTABLISH_RENDEZVOUS:
RELAY_COMMAND_INTRODUCE1:
RELAY_COMMAND_INTRODUCE2:
RELAY_COMMAND_INTRODUCE_ACK:
RELAY_COMMAND_INTRO_ESTABLISHED:
RELAY_COMMAND_RENDEZVOUS1:
RELAY_COMMAND_RENDEZVOUS2:
RELAY_COMMAND_RENDEZVOUS_ESTABLISHED:
```
It appears that anyone can send an arbitrary amount of those cells on the same circuit. Even to the point that tor allows a rendezvous circuit to become an intro circuit.
The only special one is `INTRODUCE2` which is by-design are sent a lot on the same circuit.
The only cell currently limited to 1 cell is `INTRODUCE1` since we do not allow multiple introductions on the same client circuit for DoS reasons.
But the rest should only be seen *once* on a circuit. Lets restrict them and if we see more, then we close the circuit due to a protocol error. This would limit side-channels.https://gitlab.torproject.org/tpo/core/torspec/-/issues/163We should make HSv3 desc upload less frequent2022-10-17T19:28:01ZGeorge KadianakisWe should make HSv3 desc upload less frequentWithout checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOA...Without checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOAD_TIME_MIN`).
This makes HSv3s upload descriptors more frequently than needed. For example, we could increase this to upload descriptors between 2 and 2.9 hours, to make HSv3s less intense on the network.
Someone should double check the above logic and make sure it won't cause issues, and implement it.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22341Make sure to pick up zstd+lzma support for tor in Tor Browser2023-11-09T08:42:24ZGeorg KoppenMake sure to pick up zstd+lzma support for tor in Tor BrowserWe might need to adapt our descriptors to make sure tor in Tor Browser is built with zstd+lzma support as well.
This is the parent ticket and the work, if needed, is done in child tickets.We might need to adapt our descriptors to make sure tor in Tor Browser is built with zstd+lzma support as well.
This is the parent ticket and the work, if needed, is done in child tickets.https://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.