The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:31:18Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24732Remove unused IPv6 DirPort code2021-09-16T14:31:18ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.https://gitlab.torproject.org/tpo/core/tor/-/issues/24714rename conn->timestamp_lastwritten to conn->timestamp_lastwritable2021-09-16T14:31:18ZRoger Dingledinerename conn->timestamp_lastwritten to conn->timestamp_lastwritable"lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* co..."lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* could write? */
```
It seems that we changed our definition of this word somewhere along the line, but we left the old word in place. How confusing.
We might want to change lastread to lastreadable too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24681Make the default fallback weight in Tor 10.02020-06-27T13:54:38ZteorMake the default fallback weight in Tor 10.0This is a follow-up to legacy/trac#24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks...This is a follow-up to legacy/trac#24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * 2% when 25% are down (our replacement threshold)
* 7% when 40% are down (our worst case scenario)Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24677Use ping ::1 on Linux when ping6 ::1 fails2020-06-27T13:54:38ZteorUse ping ::1 on Linux when ping6 ::1 failsTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24573rewrite_node_address_for_bridge() should set IPv6 preferences even if there ...2020-06-27T13:54:44Zteorrewrite_node_address_for_bridge() should set IPv6 preferences even if there is no rirewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-a...rewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-alpha.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24572rewrite_node_address_for_bridge() doesn't set rs IPv6 addresses2020-06-27T13:54:44Zteorrewrite_node_address_for_bridge() doesn't set rs IPv6 addressesrewrite_node_address_for_bridge() should set the IPv6 address in rs, as well as setting the one in ri. We can copy the code from ri.
This goes back to commit 9e9edf71f7d in tor 0.2.4.5-alpha.
This is unlikely to have caused any bugs si...rewrite_node_address_for_bridge() should set the IPv6 address in rs, as well as setting the one in ri. We can copy the code from ri.
This goes back to commit 9e9edf71f7d in tor 0.2.4.5-alpha.
This is unlikely to have caused any bugs since at least 0.2.8, because node_get_*_or_addr() checks the ri before the rs.
But let's fix it anyway, for consistency and better logging.
(Eventually, we will rip out this code when we make ri and rs read-only.)Tor: 0.3.3.x-finalffmanceraffmancerahttps://gitlab.torproject.org/tpo/core/tor/-/issues/24558enable expensive hardening message is wrong with static library builds2020-06-27T13:54:45Zteorenable expensive hardening message is wrong with static library buildsA user complained on IRC that using expensive hardening and static builds together resulted in this warning:
```
configure: error: The compiler supports -fsanitize=address, but for some reason I was not able to link when using it. Are yo...A user complained on IRC that using expensive hardening and static builds together resulted in this warning:
```
configure: error: The compiler supports -fsanitize=address, but for some reason I was not able to link when using it. Are you missing run-time support? With GCC you need libubsan.so, and with Clang you need libclang_rt.ubsan*
```
We should say that you need "libubsan.*" for GCC, because you need the static version for static builds.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24531sched: Add function to change scheduler state and always use it2020-06-27T13:54:46Zpastlysched: Add function to change scheduler state and always use itI'm thinking about hypothetical future debugging efforts here.
I think it would be nice to have
```
channel_set_scheduler_state(chan, new_state) {
log_changed_from_state_to_state()
chan->scheduler_state = new_state
}
```
And the...I'm thinking about hypothetical future debugging efforts here.
I think it would be nice to have
```
channel_set_scheduler_state(chan, new_state) {
log_changed_from_state_to_state()
chan->scheduler_state = new_state
}
```
And then change every instance of `chan->scheduler_state = [...]` to `channel_set_scheduler_state([...])`. Future hypothetical debugging sessions can be guaranteed to have information regarding what state each channel at all times.
Extra points if it logs some of the stuff in `scheduler_bug_occurred` too.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24509circuit_can_use_tap() should only allow TAP for v2 onion services2021-08-23T15:17:07Zteorcircuit_can_use_tap() should only allow TAP for v2 onion servicescircuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_...circuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_info that we can use for this.
This is security-low, because it's a defence in depth mechanism that doesn't provide as much defence as we thought.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24490Stop setting bridges running in networkstatus_getinfo_by_purpose()2021-09-16T14:31:40ZteorStop setting bridges running in networkstatus_getinfo_by_purpose()A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0...A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24484free(NULL) always works (nowadays) so stop acting like it might not2020-06-27T13:54:48ZTaylor Yufree(NULL) always works (nowadays) so stop acting like it might notsrc/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a...src/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a no-op since C89 at least. Some pre-ANSI platforms might have had a libc `free()` that didn't allow a null pointer, but we mostly don't care about those.
We should stop propagating this common misconception that `free(NULL)` might undefined on modern platforms. We should remove that text from the comment and remove the conditional from the implementation.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2021-08-23T15:17:07ZteorClients should check IPv4 and IPv6 subnets when choosing circuit pathsCurrently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Currently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24338DirAuths that have IPv6 addresses don't include them in their vote on themself2020-06-27T13:54:55ZTom Rittertom@ritter.vgDirAuths that have IPv6 addresses don't include them in their vote on themselfCheck out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF...Check out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF4735A19BCA1DE97281
Also strange: dannenberg votes on ReachableIPv6 but is not itself granted ReachableIPv6Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24318Clarify that the RelayBandwidth* options exclude directory fetches by relays2021-07-22T16:21:37ZteorClarify that the RelayBandwidth* options exclude directory fetches by relaysTwice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relay...Twice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relays), because that is considered "client" activity.
We should clarify in the man page, because it clearly causes some confusion.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24312Update DirCache Warning2020-06-27T13:54:56ZcypherpunksUpdate DirCache WarningWhen DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as gr...When DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as granted (not in the future), right?Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24262hs-v3: Change "hsdir-interval" to "hsdir_interval" to match the spec2020-06-27T13:54:58ZDavid Gouletdgoulet@torproject.orghs-v3: Change "hsdir-interval" to "hsdir_interval" to match the specWe've merged the consensus param used by HS v3 in dir-spec.txt (legacy/trac#24118). They all follow some sort of common naming convention using underscores instead of hyphens.
The `hsdir-interval` is the only one in the code not followi...We've merged the consensus param used by HS v3 in dir-spec.txt (legacy/trac#24118). They all follow some sort of common naming convention using underscores instead of hyphens.
The `hsdir-interval` is the only one in the code not following this. It is in `get_time_period_length()`Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24230control: HS_DESC event failed upload sends back the wrong Action2020-06-27T13:55:00ZDavid Gouletdgoulet@torproject.orgcontrol: HS_DESC event failed upload sends back the wrong ActionWhen a descriptor upload fails, tor sends on the control port a `UPLOAD_FAILED` event where in fact it should be sending a `FAILED` event as the action with the reason: `UPLOAD_REJECTED` or `UNEXPECTED`.
The `control_event_hs_descriptor...When a descriptor upload fails, tor sends on the control port a `UPLOAD_FAILED` event where in fact it should be sending a `FAILED` event as the action with the reason: `UPLOAD_REJECTED` or `UNEXPECTED`.
The `control_event_hs_descriptor_upload_failed()` is the offending function.
The control spec does not specify at all the `Action=UPLOAD_FAILED` nor Stem for instance knows about it so this is a problem on tor side.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24023Is proto required for alternate relay implementations?2021-07-22T16:21:37ZteorIs proto required for alternate relay implementations?Mike reports on tor-relays that authorities treat the "proto" line as mandatory for non-Tor implementations.
We should document that here:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n773Mike reports on tor-relays that authorities treat the "proto" line as mandatory for non-Tor implementations.
We should document that here:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n773Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24001node_get_ed25519_id() should check if the microdesc ed25519 id is all zero2020-06-27T13:55:12Zteornode_get_ed25519_id() should check if the microdesc ed25519 id is all zeroCurrently we only do this for the ri ed25519 id.
If that check is already done when we parse microdescs, we should add a comment.Currently we only do this for the ri ed25519 id.
If that check is already done when we parse microdescs, we should add a comment.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23966Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()2021-09-16T14:31:39ZteorRefactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()In legacy/trac#23577, we will create node_get_curve25519_onion_key().
We should use it to implement node_has_curve25519_onion_key(), so they give consistent results.In legacy/trac#23577, we will create node_get_curve25519_onion_key().
We should use it to implement node_has_curve25519_onion_key(), so they give consistent results.Tor: 0.3.3.x-final