Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-02-15T19:20:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25573Track half-closed stream IDs2023-02-15T19:20:48ZMike PerryTrack half-closed stream IDsIn order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox...In order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox) will hang up on streams that still have data in flight. In this case, Tor clients send RELAY_COMMAND_END when they are done with a stream, and immediately remove that stream ID from their valid stream mapping. The remaining application data continues to arrive, but is silently dropped by the Tor client. The result is that this ignored stream data currently can't be distinguished from injected dummy traffic with completely random stream IDs, and this fact can be used to mount side channel attacks.
A similar situation exists for spurious RELAY_ENDs.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25376Disable as many timers as possible when DisableNetwork or when idle/hibernating2022-05-07T06:47:11ZNick MathewsonDisable as many timers as possible when DisableNetwork or when idle/hibernatingWith legacy/trac#25373 and legacy/trac#25375, we should be using first-class timer objects for more and more of our timed events. We should have a way to mark timers that should be disabled when Tor is idle, or when DisableNetwork has ...With legacy/trac#25373 and legacy/trac#25375, we should be using first-class timer objects for more and more of our timed events. We should have a way to mark timers that should be disabled when Tor is idle, or when DisableNetwork has been set. Then we should actually disable them, to lower the amount of wakeups that Tor performs under those circumstances.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25409rip out PortForwarding options2022-03-08T17:52:12ZRoger Dingledinerip out PortForwarding optionsA relay operator on tor-relays@ just got snookered into setting PortForwarding to 1, probably because he thought it would help him get port forwarding working on his relay.
I think the reality is that almost nobody uses this option, and...A relay operator on tor-relays@ just got snookered into setting PortForwarding to 1, probably because he thought it would help him get port forwarding working on his relay.
I think the reality is that almost nobody uses this option, and also we don't recommend it.
Yawning rewrote the crappy dangerous C upnp apps in go:
https://gitweb.torproject.org/tor.git/tree/src/tools/tor-fw-helper/README
https://gitweb.torproject.org/tor-fw-helper.git/tree/README.md
But I don't think we've taken any steps to get that go version into any user's hands.
Also, our past use case, where Vidalia would launch Tor and want to let ordinary users turn themselves into relays or bridges, is long deprecated.
Alternatives to "rip it out" would be "get yawning's go stuff packaged properly in Debian", or "add yawning's go stuff to the tor tarball and build it and ship it too".
See also legacy/trac#21765 and its great phrase "I wonder how long this has been broken for".Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2021-09-30T13:50:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24977Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, ...2021-09-30T13:50:08ZGeorge KadianakisNon-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))This one is back, since pre-release days of hsv3. Something makes it such that the hsdir index is not well set for some relays.
I got this to happen on my hsv3 service a few weeks ago. I got it a few times on the same second for the sam...This one is back, since pre-release days of hsv3. Something makes it such that the hsdir index is not well set for some relays.
I got this to happen on my hsv3 service a few weeks ago. I got it a few times on the same second for the same node, and then it got fixed... There were no other references to that node (or its fpr) before that.
```
Jan 04 21:30:54.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_common.:1277: node_has_hsdir_index: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) failed. (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) failed in node_has_hsdir_index at src/or/hs_common.c:1277. Stack trace: (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42) [0x7f6079a21db2] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7f6079a3cc57] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(hs_get_responsible_hsdirs+0x4f9) [0x7f6079a046c9] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(hs_service_run_scheduled_events+0x1a5b) [0x7f6079a11c5b] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x4b9f1) [0x7f60798ed9f1] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x6b4f0) [0x7f607990d4f0] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f6078f253dc] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x244) [0x7f60798f0eb4] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x1c25) [0x7f60798f46f5] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(main+0x19) [0x7f60798ec629] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f60781182b1] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a) [0x7f60798ec67a] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
Jan 04 21:30:55.000 [info] hs_get_responsible_hsdirs(): Node $EEC47B34F9403AA7F765D070BB3011E50A373C21~ivanmk2 at 185.22.173.162 was found without hsdir index.
Jan 04 21:30:55.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
```Tor: 0.3.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/26523HSPOST command doesn't parse HSADDRESS argument2021-09-30T13:46:30ZTracHSPOST command doesn't parse HSADDRESS argumentThe HSPOST command ignores the HSADDRESS argument unless a SERVER argument precedes it, and incorrectly parses the argument (the argument name and = sign are treated as part of the address).
The command returns a synchronous 250 OK resp...The HSPOST command ignores the HSADDRESS argument unless a SERVER argument precedes it, and incorrectly parses the argument (the argument name and = sign are treated as part of the address).
The command returns a synchronous 250 OK response for v2 descriptors, but not for v3 descriptors.
**Trac**:
**Username**: akwizgranTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26069hs-v3: Descriptor signature parsing should have a trailing white-space2021-09-30T13:46:30ZDavid Gouletdgoulet@torproject.orghs-v3: Descriptor signature parsing should have a trailing white-spaceFrom ticket legacy/trac#25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in legacy/trac#25552 for 034 b...From ticket legacy/trac#25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in legacy/trac#25552 for 034 but we need to backport it back to 030 when it was first introduced. It won't affect any tor version on the ability to parse service descriptors. It will just reinforce the security and correctness.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25967v3 onion keep working without the HiddenServiceVersion 3 line2021-09-30T13:46:30Zcypherpunksv3 onion keep working without the HiddenServiceVersion 3 lineI started by defining a v3 hidden service in torrc and running tor, thus creating a v3 private key.
Then I commented out the HiddenServiceVersion 3 line and sent the tor process a sighup using kill -HUP processid.
The v2 private key a...I started by defining a v3 hidden service in torrc and running tor, thus creating a v3 private key.
Then I commented out the HiddenServiceVersion 3 line and sent the tor process a sighup using kill -HUP processid.
The v2 private key and hostname were generated, but the v3 address kept working the v2 address did not work.
I then sent sighup again, and this time both the v2 and v3 addresses worked.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25939A Tor commit seems to have broken creation of V3 onion services with stem2021-09-30T13:46:30ZTracA Tor commit seems to have broken creation of V3 onion services with stemThe commit in question is [this](https://gitweb.torproject.org/tor.git/commit/?id=a4fcdc5decfe60bbd95aee2e5586e90c40b73225).
[Here](https://gist.github.com/maqp/5ea6cf41a836c290b22ec302213d8a00) is a bash script that helps reproduce the...The commit in question is [this](https://gitweb.torproject.org/tor.git/commit/?id=a4fcdc5decfe60bbd95aee2e5586e90c40b73225).
[Here](https://gist.github.com/maqp/5ea6cf41a836c290b22ec302213d8a00) is a bash script that helps reproduce the bug. By default the script uses the [last working commit](https://gitweb.torproject.org/tor.git/commit/?id=ed89bb32535fbf354b406a36f3176380a4e226bf). Comment line 22 and uncomment line 23 and run it again to see how the [python script](https://gist.githubusercontent.com/maqp/bf2d14ec625556997ae075d2084b4a4c/raw/6a4353336a76350b7511bd65dcc6183efb6bf215/v3_onion_test.py) launched by the bash script is unable to bring V3 onion service online with stem.
**Trac**:
**Username**: maqpTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25901hs-v3: Memleak on SIGHUP2021-09-30T13:46:29ZDavid Gouletdgoulet@torproject.orghs-v3: Memleak on SIGHUPOn SIGHUP, we move the hs state between service objects.
Because `hs_service_new()` allocates the replaycache by default, we overwrite it within `move_hs_state()`:
```
dst->replay_cache_rend_cookie = src->replay_cache_rend_cookie;
``...On SIGHUP, we move the hs state between service objects.
Because `hs_service_new()` allocates the replaycache by default, we overwrite it within `move_hs_state()`:
```
dst->replay_cache_rend_cookie = src->replay_cache_rend_cookie;
```
We have to free the `dst` cache before.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25761hs: Reload signal (HUP) doesn't remove a disabled service2021-09-30T13:46:29ZDavid Gouletdgoulet@torproject.orghs: Reload signal (HUP) doesn't remove a disabled serviceReported by a user on tor-onions@:
https://lists.torproject.org/pipermail/tor-onions/2018-April/000265.html
I can confirm that on 0.3.2, commenting the hidden service options in the torrc file and then HUP does NOT disable it for which...Reported by a user on tor-onions@:
https://lists.torproject.org/pipermail/tor-onions/2018-April/000265.html
I can confirm that on 0.3.2, commenting the hidden service options in the torrc file and then HUP does NOT disable it for which it should!
Both v2 and v3 are affected. So somehow, we broke that feature in 032. I'm putting this in 034 milestone and mark it for possible backport.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6236Remove duplicate code between parse_{c,s}method_line2021-09-16T14:36:00ZGeorge KadianakisRemove duplicate code between parse_{c,s}method_line`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.`parse_{c,s}method_line` share lots of duplicate code. We must find a way to merge the two functions, or hide the duplicate code into functions.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15015tor --verify-config should not bind to ports2021-09-16T14:35:00Zcypherpunkstor --verify-config should not bind to portshttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlhttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlTor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/18918Clarify directory and ORPort checking functions2021-09-16T14:34:12ZteorClarify directory and ORPort checking functionsThe OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_...The OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_orport_reachable
* check_whether_dirport_reachable
* router_has_bandwidth_to_be_dirserver
* router_should_be_directory_server
* dir_server_mode
* decide_to_advertise_dirport
* consider_testing_reachabilityTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19429Clean up our OpenSSL 1.1 support.2021-09-16T14:33:30ZYawning AngelClean up our OpenSSL 1.1 support.In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we...In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we provided our own wrappers for a more unified codepath.
Neither of these are high priority as the current code works, the changes suggested would just make things better.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2021-09-16T14:33:04ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in legacy/trac#20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23354Remove deterministic download schedule code and configs2021-09-16T14:32:00ZteorRemove deterministic download schedule code and configsUnder exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most ca...Under exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most cases, the random amount is much smaller than the maximum, so we could replace the item with the actual maximum, or delete it from the schedule altogether. (On the public network, the maximum is 4x the last entry, on test networks, it's 3x.)~~
So once we're sure that we will never revert to deterministic schedules, we should make each schedule into a single initial value, and remove the deterministic code.
We should make these changes based on the schedules in legacy/trac#23347.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23873Remove the return value of node_get_prim_orport()2021-09-16T14:31:39ZteorRemove the return value of node_get_prim_orport()~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null ad...~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null address instead.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23750Isolate libevent usage to a few locations2021-09-16T14:31:39ZNick MathewsonIsolate libevent usage to a few locationsWith legacy/trac#21841, we restricted openssl header usage to a small number of modules. We should do the same with libevent.With legacy/trac#21841, we restricted openssl header usage to a small number of modules. We should do the same with libevent.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25494Initial work on making modules conditionally compiled2021-09-16T14:31:19ZDavid Gouletdgoulet@torproject.orgInitial work on making modules conditionally compiledThis is a roadmap master ticket. The idea is to try to extract modules out of Tor into compile time options in order to help the modularization effort and shrinking the binary size down for mobile.
See child tickets for more specific ta...This is a roadmap master ticket. The idea is to try to extract modules out of Tor into compile time options in order to help the modularization effort and shrinking the binary size down for mobile.
See child tickets for more specific tasks.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org