The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-18T18:10:37Zhttps://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/17343Add torrc option OnionService* alias for HiddenService*2022-10-20T22:33:53ZDavid Gouletdgoulet@torproject.orgAdd torrc option OnionService* alias for HiddenService*Since the rebranding of Hidden Service to "Onion Service" is now a thing, it would make sense to add aliases for every hidden service torrc option to be changed to use "OnionService" instead. Here are the options I can find in tor man pa...Since the rebranding of Hidden Service to "Onion Service" is now a thing, it would make sense to add aliases for every hidden service torrc option to be changed to use "OnionService" instead. Here are the options I can find in tor man page:
```
HidServAuth --> OnionServiceAuth
HidServDirectoryV2 --> OnionServiceDirectoryV2
MinUptimeHidServDirectoryV2 --> MinUptimeOnionServiceDirectoryV2
VoteOnHidServDirectoriesV2 --> VoteOnOnionServiceDirectoriesV2
PublishHidServDescriptors --> PublishOnionServiceDescriptors
FetchHidServDescriptors --> FetchOnionServiceDescriptors
HiddenService* --> OnionService*
```
Just to be clear, it's NOT a renaming but we add an alias for the current options so both live together.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-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17134Add a way to say "Use this option only if supported" in torrc2021-06-18T18:15:52ZNick MathewsonAdd a way to say "Use this option only if supported" in torrcIt would be nice to have a torrc that sets some option _when Tor supports that option_, but not otherwise (eg when older versions of Tor read it).
There are two ways to do this I can think of:
1. **Future-compatible only**
We could ha...It would be nice to have a torrc that sets some option _when Tor supports that option_, but not otherwise (eg when older versions of Tor read it).
There are two ways to do this I can think of:
1. **Future-compatible only**
We could have a new syntax, something like `?Option Value`. Meaning: if the option is prefixed with a question mark, it does not cause an error when unrecognized. (It _should_ cause a warning.)
2. **Backward-compatible too, kinda ugly**
We could have a syntax that old Tor versions interpret as a comment, but which new Tor versions interpret as above. My first thought is to use some magic string like `#$%^option value`. This could cause problems if anybody is actually writing comments like that.https://gitlab.torproject.org/tpo/core/tor/-/issues/17120Fire a circuit status control port event when circuit isolation changes.2020-07-24T18:11:20ZYawning AngelFire a circuit status control port event when circuit isolation changes.Followup from legacy/trac#17086.
Currently trying to track circuit isolation status via control port events is non-trivial/impossible without polling due to predictive circuits and other non-SOCKS initiated circuits being used to servic...Followup from legacy/trac#17086.
Currently trying to track circuit isolation status via control port events is non-trivial/impossible without polling due to predictive circuits and other non-SOCKS initiated circuits being used to service SOCKS requests.
The current behavior is correct according to the control port spec, since the username/password are only provided when the circuit was initiated via a SOCKS request, and is silent about `BUILT` circuits being used to immediately service a request.
This *should* be easy to do, but requires a control spec change and is an enhancement so it's a 0.2.8.x thing at the earliest.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17038Provide scripts to set up transparent proxying, where supported2022-06-17T17:55:24ZTracProvide scripts to set up transparent proxying, where supportedSetting up a transparent TOR proxy is quite complicated when it comes to firewall rules (e.g. IPTables). Any configuration slip breaks the anonymity.
So I suggest to add the options '[Trans{Local|MiddleBox}](uploads/TransProxyLocal)IPv{...Setting up a transparent TOR proxy is quite complicated when it comes to firewall rules (e.g. IPTables). Any configuration slip breaks the anonymity.
So I suggest to add the options '[Trans{Local|MiddleBox}](uploads/TransProxyLocal)IPv{4|6}' to torrc which automagically configure a transparent TOR proxy with all necessary settings (e.g. IPTables rules, system resolver set-up with .onion).
**Trac**:
**Username**: rennehttps://gitlab.torproject.org/tpo/core/tor/-/issues/17028silently ignore a bad/missing --defaults-torrc2020-06-27T20:40:08ZLunarsilently ignore a bad/missing --defaults-torrcThe nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-exi...The nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-existing file.
At least a warning would be good, but I think it would be even better to bail out unless `--ignore-missing-torrc` is specified.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16846Include sizeof(void *) in your extrainfo.2020-06-27T14:00:48ZYawning AngelInclude sizeof(void *) in your extrainfo.From legacy/trac#16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we ca...From legacy/trac#16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it safely.