Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-11T23:40:19Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19328Try not to log from inside functions called from inside log functions2022-10-11T23:40:19ZNick MathewsonTry not to log from inside functions called from inside log functionsOur logging code is technically recursive now. Logging asks what the time is and tries to format it. Formatting the time can fail. Failures can log.Our logging code is technically recursive now. Logging asks what the time is and tries to format it. Formatting the time can fail. Failures can log.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18642Teach the OOM handler about the DNS cache2022-10-11T23:40:18ZNick MathewsonTeach the OOM handler about the DNS cacheTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17927Use SRWLock for non-recursive locks on vista and later2021-09-16T14:34:35ZNick MathewsonUse SRWLock for non-recursive locks on vista and laterAfter WinXP, Windows added the SRWLock type, which is generally much faster than CRITICAL_SECTION, and supports RW semantics. It doesn't support recursive usage, though it can be hacked in.
I'm calling this 0.2.??? since we have no evi...After WinXP, Windows added the SRWLock type, which is generally much faster than CRITICAL_SECTION, and supports RW semantics. It doesn't support recursive usage, though it can be hacked in.
I'm calling this 0.2.??? since we have no evidence that locking is anywhere close to our critical path. But who knows; perhaps it is? Or will be, once we do more things in workers?Tor: 0.3.5.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17873replacing 0.0.0.0 listeners at runtime fails2020-06-27T13:59:56Zcypherpunksreplacing 0.0.0.0 listeners at runtime failsI had DNSPort 0.0.0.0:53 set. Some jerks on the internet started flooding me with DNS requests so I reconfigured tor to only have the DNSPort on my LAN interface. I sent tor a HUP to reload the config, and it exited because it tried to b...I had DNSPort 0.0.0.0:53 set. Some jerks on the internet started flooding me with DNS requests so I reconfigured tor to only have the DNSPort on my LAN interface. I sent tor a HUP to reload the config, and it exited because it tried to bind the new listener before unbinding the old one:
```
Dec 16 16:19:51.000 [notice] Opening DNS listener on 172.16.0.1:53
Dec 16 16:19:51.000 [warn] Could not bind to 172.16.0.1:53: Permission denied
Dec 16 16:19:51.000 [notice] Closing no-longer-configured DNS listener on 0.0.0.0:53
Dec 16 16:19:51.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Dec 16 16:19:51.000 [err] Reading config failed--see warnings above. For usage, try -h.
Dec 16 16:19:51.000 [warn] Restart failed (config error?). Exiting.
```Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see legacy/trac#15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-27T14:02:28ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8494Document MaxAdvertisedBandwidth in the bandwidth list spec2020-06-27T14:04:35ZTracDocument MaxAdvertisedBandwidth in the bandwidth list specI've set MaxAdvertisedBandwidth to 100 KB (though RelayBandwidthRate and RelayBandwidthBurst are set to 128 KB and 153 KB, respectively). Accordingly, the relay does not advertise any bandwidth higher than 100 KB. However, the consensus...I've set MaxAdvertisedBandwidth to 100 KB (though RelayBandwidthRate and RelayBandwidthBurst are set to 128 KB and 153 KB, respectively). Accordingly, the relay does not advertise any bandwidth higher than 100 KB. However, the consensus is reporting greater bandwidth:
`valid-after 2013-03-17 01:00:00`
`r PrivateJoker hWF85kNElIsLrCPNTiIkX39mwcg r5DGWEd9ufF4TFXJITuOhw+by6I 2013-03-16 19:18:56 107.197.196.79 443 80`
`s Fast Named Running Stable V2Dir Valid`
`v Tor 0.2.4.11-alpha`
`w Bandwidth=108`
`p reject 1-65535`
The bandwidth line from the descriptor looks like:
```
bandwidth 102400 156672 155648
```
My understanding is that clients use the consensus bandwidth measurement to weigh which paths to choose (correct me if I'm wrong). If this is true, then the consensus should not report bandwidth greater than MaxAdvertisedBandwidth. Perhaps the consensus should never show bandwidth greater than a relay's chosen RelayBandwidthRate?
**Trac**:
**Username**: alphawolfTor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/8415Use event_set_mem_functions2022-04-29T21:02:58ZNick MathewsonUse event_set_mem_functionsWe should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.We should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8323Missing 'GETINFO md/all'2020-06-27T14:04:41ZDamian JohnsonMissing 'GETINFO md/all'Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is ...Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is a pretty common need, hence the priority (feel free to lower it if appropriate). In the meantime I'll hack around this in stem by having controller read microdescriptors from the data directory.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/4700Tor should provide a mechanism for hidden services to differentiate authorize...2020-06-27T14:07:09ZTracTor should provide a mechanism for hidden services to differentiate authorized clients and circuitsTor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exporte...Tor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exported.
**Trac**:
**Username**: katmagicTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3723Report version of bwscanners in votes2020-06-27T14:07:56ZMike PerryReport version of bwscanners in votesEach directory authority should list the git version of the bandwidth scanners in their votes. This ticket has two parts:
1. Edit aggregate.py to output a line with the git commit that it is from.
2. Alter the tor voting to add an "opt...Each directory authority should list the git version of the bandwidth scanners in their votes. This ticket has two parts:
1. Edit aggregate.py to output a line with the git commit that it is from.
2. Alter the tor voting to add an "opt" line or other ignored keyword that lists the version from the bwscan file.
There should be no consensus process for this. We just want a comment in the vote documents, basically.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3569Refactor socks parsing2021-09-16T14:36:24ZNick MathewsonRefactor socks parsingThe function parse_socks and its interactions with the functions that call it have grown nigh-unmaintainably complex. Let's replace it with a simple, more linear function. Key points:
* State should be kept explicitly. Let's forget...The function parse_socks and its interactions with the functions that call it have grown nigh-unmaintainably complex. Let's replace it with a simple, more linear function. Key points:
* State should be kept explicitly. Let's forget this "if the socks version is set, we've parsed this much, ..." business.
* The function should dispatch first on state, next on anything else.
* We should think of a much better interface; the functions that call parse_socks have grown way too tricky.Tor: 0.3.5.x-finalrl1987rl1987