The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:00:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17779Memory leak in routerkeys.c2020-06-27T14:00:04ZcypherpunksMemory leak in routerkeys.cThe `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the...The `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the current code base.
My suggestion is to remove the `rsa_ed_crosscert` variable and the `get_master_rsa_crosscert` function to fix the memory leak (unless they have some future use-case).
The variable and function were added in 3bee74c6d115131f4850a07a5c12db21ae6f3193.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17758inaccurate log line (-1 out of 360)2020-06-27T14:00:06ZRoger Dingledineinaccurate log line (-1 out of 360)I ran out of disk space, and saw this in my logs:
```
Dec 05 03:08:36.663 [warn] Couldn't dump microdescriptor (wrote -1 out of 360): No space left on device
```
Did it really un-write one of the bytes? :)I ran out of disk space, and saw this in my logs:
```
Dec 05 03:08:36.663 [warn] Couldn't dump microdescriptor (wrote -1 out of 360): No space left on device
```
Did it really un-write one of the bytes? :)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17751Use router_get_my_routerinfo() rather than desc_routerinfo2020-06-27T14:00:06ZteorUse router_get_my_routerinfo() rather than desc_routerinfoThe following functions use desc_routerinfo where they could use router_get_my_routerinfo():
* check_descriptor_ipaddress_changed
* router_compare_to_my_exit_policy
* router_my_exit_policy_is_reject_star
* router_get_my_descriptor
* chec...The following functions use desc_routerinfo where they could use router_get_my_routerinfo():
* check_descriptor_ipaddress_changed
* router_compare_to_my_exit_policy
* router_my_exit_policy_is_reject_star
* router_get_my_descriptor
* check_descriptor_bandwidth_changed
This could cause issues if desc_routerinfo needs to be rebuilt, because some of these functions don't call router_get_my_routerinfo() first.
Others have comments about desc_routerinfo that might need to be updated:
* dirserv_get_routerdescs
* router_compare_to_my_exit_policy
* Also change "IPv6 and IPv6 entries" to "IPv4 and IPv6 entries"Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17744Add quotes when comparing strings in configure script2020-06-27T14:00:07ZcypherpunksAdd quotes when comparing strings in configure scriptIn ticket:16651#comment:28 missing quotes caused parsing errors. The configure script still contains instances of strings being compared without quotes. AFAIK these remaining cases do not cause any problems right now but it is better to ...In ticket:16651#comment:28 missing quotes caused parsing errors. The configure script still contains instances of strings being compared without quotes. AFAIK these remaining cases do not cause any problems right now but it is better to fix them now to avoid problems in the future.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17740Unit Tests for Recent Consensuses2020-07-27T18:15:32ZteorUnit Tests for Recent ConsensusesIt would be great to have unit tests for the functions that return a recent consensus:
Mock:
* networkstatus_get_latest_consensus_by_flavor
Test:
* networkstatus_get_latest_consensus
* networkstatus_get_reasonably_live_consensus
* netw...It would be great to have unit tests for the functions that return a recent consensus:
Mock:
* networkstatus_get_latest_consensus_by_flavor
Test:
* networkstatus_get_latest_consensus
* networkstatus_get_reasonably_live_consensus
* networkstatus_consensus_is_boostrappingTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17739Refactor clock skew warning code to avoid duplication2021-09-16T14:34:35ZteorRefactor clock skew warning code to avoid duplicationThe following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.The following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17728Use NETINFO handshake rather than date header to check time with authorities2021-06-18T18:10:37ZteorUse NETINFO handshake rather than date header to check time with authoritiestor currently checks its clock against the directory authorities by reading the HTTP date header in the directory documents.
In legacy/trac#15775, we allow clients to bootstrap using fallback directories, rather than authorities.
In le...tor currently checks its clock against the directory authorities by reading the HTTP date header in the directory documents.
In legacy/trac#15775, we allow clients to bootstrap using fallback directories, rather than authorities.
In legacy/trac#4483, we make multiple connections, and use the first connection that starts downloading. If there are multiple connections downloading, we favour authority connections, so that tor can still get a clock check.
But if tor used the date from ~~the TLS handshake~~, it could get directory documents from a fallback directory, and abort authority connections sooner. This would place less load on the authorities.
This would be similar to the tlsdate implementation:
https://github.com/ioerror/tlsdate
Edited: Look at the netinfo cell, not the TLS handshake. -- nickmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17715Write unit tests for directory_initiate_command_rend2020-06-27T14:00:08ZteorWrite unit tests for directory_initiate_command_rendTo do this:
* Mock connection_connect to do nothing and return 0
* Mock directory_send_command to do nothing
* Mock connection_ap_make_link to return a fake connection
* just return the partner connection that's passed to it?
It would...To do this:
* Mock connection_connect to do nothing and return 0
* Mock directory_send_command to do nothing
* Mock connection_ap_make_link to return a fake connection
* just return the partner connection that's passed to it?
It would be nice to get this done in 0.2.8, but I think it's more likely to be 0.2.9.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17683Fail when TLS context fails to initialise2020-06-27T14:00:11ZteorFail when TLS context fails to initialise```
+ log_info(LD_GENERAL,"Rotating tls context.");
+ if (router_initialize_tls_context() < 0) {
+ log_warn(LD_BUG, "Error reinitializing TLS context");
+ /* XXX is it a bug here, that we just keep going? -RD */
}
```
I think...```
+ log_info(LD_GENERAL,"Rotating tls context.");
+ if (router_initialize_tls_context() < 0) {
+ log_warn(LD_BUG, "Error reinitializing TLS context");
+ /* XXX is it a bug here, that we just keep going? -RD */
}
```
I think it is - how about we assert() here, and see what happens?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17682safe_timer_diff is unsafe under wrapping2020-06-27T14:00:11Zteorsafe_timer_diff is unsafe under wrappingsafe_timer_diff is meant to avoid overflow (or perhaps negative return values) but doesn't. (It was introduced to tor 0.2.8.0-alpha-dev in legacy/trac#3199.)
For example:
* safe_timer_diff(INT_MIN, INT_MAX) returns -1 on a system where ...safe_timer_diff is meant to avoid overflow (or perhaps negative return values) but doesn't. (It was introduced to tor 0.2.8.0-alpha-dev in legacy/trac#3199.)
For example:
* safe_timer_diff(INT_MIN, INT_MAX) returns -1 on a system where TIME_T_IS_SIGNED. It should return a (clipped) value representing the largest integer difference possible, such as INT_MAX.
I'm sure there are equivalent issues where TIME_T_IS_UNSIGNED, but I can't think of any right now.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17638Make ersatz_socketpair work on IPv6-only systems:2020-06-27T14:00:14ZteorMake ersatz_socketpair work on IPv6-only systems:Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have I...Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have IPv6 localhost (some FreeBSD jails). Instead, they have a non-127/8, non-::1 IP address used as the default:
ersatz_socketpair currently uses INADDR_LOOPBACK. On IPv6, it should use ::1 (or a constant or function returning it). If that fails with E(address not found) (or WSAE(address not found) on Windows), that's actually what we want - we don't want to accidentally expose a socketpair on a routable address.
We should also remove the check in the ersatz_socketpair unit test that bails out on EPROTONOSUPPORT.
Patch on a version before 22dba27d8dd5 (23 Nov 2004) / svn:r2943.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17608Refactor accept/reject * redundancy checks out of policies_parse_exit_policy_...2021-09-16T14:34:34ZteorRefactor accept/reject * redundancy checks out of policies_parse_exit_policy_internalpolicies_parse_exit_policy_internal would be a lot easier to read if the code that implements `found_final_effective_entry` was in its own function.policies_parse_exit_policy_internal would be a lot easier to read if the code that implements `found_final_effective_entry` was in its own function.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17602'HidServDirectoryV2 0' not disabling HSDir2021-07-22T16:25:32Zseeess'HidServDirectoryV2 0' not disabling HSDirtorrc:
DirPort 9
ORPort 443
#ControlPort 9051
#CookieAuthentication 1
Exitpolicy reject *:*
Nickname xxx
ContactInfo xxx
SocksPort 0
#BridgeRelay 1
#ServerTransportPlugin obfs3 exec /usr/local/bin/obfsproxy managed
#ExtORPort ...torrc:
DirPort 9
ORPort 443
#ControlPort 9051
#CookieAuthentication 1
Exitpolicy reject *:*
Nickname xxx
ContactInfo xxx
SocksPort 0
#BridgeRelay 1
#ServerTransportPlugin obfs3 exec /usr/local/bin/obfsproxy managed
#ExtORPort auto
User debian
DataDirectory /usr/local/etc/tor
BandwidthRate 6MBytes
BandwidthBurst 10MBytes
AvoidDiskWrites 1
#TunnelDirConns 1
#PreferTunneledDirConns 1
EntryStatistics 1
ConnDirectionStatistics 1
HidServDirectoryV2 0
HiddenServiceStatistics 1
#DisableDebuggerAttachment 0 #needed for arm stats
Log notice stdout
Log [rend,net,config,dir]info
Both atlas and globe show my relay having the "HSDir" flag, this torrc configuration was last changed on oct 25, and the tor process (and whole computer) was restarted since then.
I probably shouldn't be setting "HiddenServiceStatistics 1" anymore, but shouldn't HidServDirectoryV2 0 supersede HiddenServiceStatistics?
Is the relay being a v1 hidden service directory? I thought v1 was only for auth dirs?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17573Update max_dl_per_request for IPv6 address length2020-06-27T14:00:18ZteorUpdate max_dl_per_request for IPv6 address lengthmax_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets...max_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets.)
While we're doing that, it would be nice to add a comment with the microdescriptor length calculation as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17520Relax the rend cache failure cleanup timer2022-06-17T17:37:27ZDavid Gouletdgoulet@torproject.orgRelax the rend cache failure cleanup timer`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technical...`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technically grow to the number of possible introduction point in the network thus making it a larger loop every second.
Let's relax the cleanup timer here to 5 minutes (expiry time of an entry) and at each lookup, if the entry did expire, clean it and return that "we do not have an entry". This will not address the size of the cache that can grows but that's fine since we can handle that in the OOM. Also, a cache that has the maximum number of entries is a valid use case.https://gitlab.torproject.org/tpo/core/tor/-/issues/17233MinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?2021-06-18T18:15:52ZRoger DingledineMinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?https://gitlab.torproject.org/tpo/core/tor/-/issues/17225Merge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIME2021-09-16T14:35:00ZteorMerge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIMEThese are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.These are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.https://gitlab.torproject.org/tpo/core/tor/-/issues/17224Refactor common parts of parse_dir_authority_line and parse_dir_fallback_line2021-09-16T14:35:00ZteorRefactor common parts of parse_dir_authority_line and parse_dir_fallback_lineThere's a lot of common code in parse_dir_authority_line and parse_dir_fallback_line that could be refactored into a shared function.
What needs to be done is:
* identify common code
* create a common loop that parses the key=value pair...There's a lot of common code in parse_dir_authority_line and parse_dir_fallback_line that could be refactored into a shared function.
What needs to be done is:
* identify common code
* create a common loop that parses the key=value pairs it understands, deletes them, and leaves the rest alone
* put that loop in its own function that takes pointers (or pointer pointers?), returns values in those that are included, and returns NULL in those that aren't.
* check this loop's output from both functions to ensure they each get what they need, then do the specific bits on the remaining arguments
* call a common function to parse the IPv4:Port at the start of the line, then delete it
* call a common function to parse the hex digest, which should be the only remaining thinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17188Tor should warn users when traveling backwards through time2021-08-23T15:17:35ZTracTor should warn users when traveling backwards through timeAn attacker can do evil things by rewinding a user's clock, without having to own their machine (e.g., NTP attacks).
Tor maintains a monotonic clock to prevent rewinding attacks while Tor is running. Tor also keeps some persistent info...An attacker can do evil things by rewinding a user's clock, without having to own their machine (e.g., NTP attacks).
Tor maintains a monotonic clock to prevent rewinding attacks while Tor is running. Tor also keeps some persistent information about the user's time in the state file, in the LastWritten field.
On launch, if Tor sees that the system time has been rewound to before the LastWritten time, it should warn the user that something strange is happening. However, Tor should not update the monotonic clock or fail to launch, since the user may have changed the time deliberately.
**Trac**:
**Username**: hdevalenceTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17153tor test networks should allow IPv6 private addresses2020-06-27T14:00:34Zteortor test networks should allow IPv6 private addresses`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows privat...`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows private addresses in descriptors for IPv4. It should do that for IPv6 as well.Tor: 0.2.8.x-final