The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:21:37Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25203document max. value of SigningKeyLifetime2021-07-22T16:21:37Zcypherpunksdocument max. value of SigningKeyLifetimetor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys tha...tor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime.
> (Default: 30 days)
It does not include information about what is the biggest acceptable value. Tor simply fails to start if the given value is to big:
```
[warn] Interval 'XX months' is too long
[warn] Failed to parse/validate config: Interval 'SigningKeyLifetime XX months' is malformed or out of bounds.
```
Please also mention if there is a value for SigningKeyLifetime where it is actually less safe than running in non-OfflineMasterKey mode (maybe it is less safe to set it to 10y in OfflineMasterKey mode than to run in non-OfflineMasterKey mode?) and if it makes any sense to modify this value in non-OfflineMasterKey mode (because that is apparently possible).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25116hs: circuit_log_ancient_one_hop_circuits() should probably not log single oni...2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuitAssume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circ...Assume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circuit_log_ancient_one_hop_circuits()` to log single hop circuits.
I think we want to ignore to log anything service related in there. Some v3 services have started seeing that heartbeat more and more in the last days.
Related: legacy/trac#8387Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25110Warn operators who set MyFamily that they must also set ContactInfo2020-11-04T14:18:57ZteorWarn operators who set MyFamily that they must also set ContactInfoWe added this advice to the man page in ~~0.3.2.9~~ 0.3.2.10, but a config warning could help, too.
The logic is:
If an operator sets MyFamily, and does not set ContactInfo:
* warn the operator that they should set ContactInfoWe added this advice to the man page in ~~0.3.2.9~~ 0.3.2.10, but a config warning could help, too.
The logic is:
If an operator sets MyFamily, and does not set ContactInfo:
* warn the operator that they should set ContactInfoTor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25108hs: nodelist_recompute_all_hsdir_indices() is not used2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: nodelist_recompute_all_hsdir_indices() is not usedDead code that we should remove.Dead code that we should remove.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25097Remove commented functions in crypto module2020-06-27T13:54:16ZffmanceraRemove commented functions in crypto moduleI noticed there are some code commented in crypto module.
* struct CRYPTO_dynlock_value
* openssl_dynlock_create_cb_
* openssl_dynlock_lock_cb_
* openssl_dynlock_destroy_cb_
OpenSSL never uses these callbacks anymore so the code i...I noticed there are some code commented in crypto module.
* struct CRYPTO_dynlock_value
* openssl_dynlock_create_cb_
* openssl_dynlock_lock_cb_
* openssl_dynlock_destroy_cb_
OpenSSL never uses these callbacks anymore so the code is disabled. Should we remove this code?Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25081use get_uptime() consistently2020-06-27T13:54:16ZRoger Dingledineuse get_uptime() consistentlyWe have this nice function get_uptime() that shields the global variable `stats_n_seconds_working` from the rest of the Tor files.
But then we undermine that by saying
```
extern long stats_n_seconds_working;
```
in main.h and we just s...We have this nice function get_uptime() that shields the global variable `stats_n_seconds_working` from the rest of the Tor files.
But then we undermine that by saying
```
extern long stats_n_seconds_working;
```
in main.h and we just start using that variable directly all over.
There are a few lonely users of get_uptime().
We should move everybody over to using get_uptime, and get rid of the scary extern.
(Also check out how we're *writing* to the extern variable, in hibernate.c. There's no way that could confuse anybody down the road!)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24991relay frequently claiming "missing descriptors for 1/2 of our primary entry g...2021-09-30T13:50:08Zalecmuffettrelay frequently claiming "missing descriptors for 1/2 of our primary entry guards"This is the first of a pair of bugs with the same logfiles, so unless requested I'll only attach the logs once, here, unless there's a real need to duplicate them.
I have an EOTK SingleOnion, config attached.
Per the logfile, it is bo...This is the first of a pair of bugs with the same logfiles, so unless requested I'll only attach the logs once, here, unless there's a real need to duplicate them.
I have an EOTK SingleOnion, config attached.
Per the logfile, it is both HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode.
It's from "dropsafezeahmyho" which is the onion for my personal blog (dropsafe.crypticide.com) which is very low traffic as an Onion, in fact it exists mostly as a test onion.
Issue #1 - after an extended period of uptime, tor claims:
```
Jan 21 08:45:04.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 5975/6006).
Jan 21 08:45:04.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 5975/6006).
```
...which should not be happening, because (as a single onion) there are no Guards.
Issue 2 will be described in the next ticket, and linked back to this one.
Attachments: logfile and configfile.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24904Make geoip use channel_is_client so it ignores flapping relays2021-09-16T14:31:18ZteorMake geoip use channel_is_client so it ignores flapping relaysIn channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_kn...In channel_do_open_actions(), we probably want to use channel_is_client() rather than connection_or_digest_is_known_relay().
```
/* only report it to the geoip module if it's not a known router */
if (!connection_or_digest_is_known_relay(chan->identity_digest)) {
if (channel_get_addr_if_possible(chan, &remote_addr)) {
```
Bugfix on legacy/trac#23533, 0.3.0.1-alpha.
We should make sure legacy/trac#24898 is fixed in any version we backport this to.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24847Merge HS v3 prop284 into control-spec.txt2020-06-27T13:54:28ZDavid Gouletdgoulet@torproject.orgMerge HS v3 prop284 into control-spec.txtProposal 284 has now been merged, it needs to be put in the control-spec.txt.Proposal 284 has now been merged, it needs to be put in the control-spec.txt.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24838Fuzzy match the fallback whitelist2020-06-27T13:54:29ZteorFuzzy match the fallback whitelistWe can rely on Onionoo to tell us when relay fingerprints or addresses change, so we don't need to do an exact match.
But listing fingerprints, addresses and ports in the whitelist is useful so that we know what a relay operator origina...We can rely on Onionoo to tell us when relay fingerprints or addresses change, so we don't need to do an exact match.
But listing fingerprints, addresses and ports in the whitelist is useful so that we know what a relay operator originally asked for.
Fuzzy matching simplifies maintaining the fallback whitelist, because we don't have to ask operators to update their relay details. (Or ask if those details are permanent.)
We deleted the blacklist in legacy/trac#26502.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24740Tor launches two requests for authority certificates on first bootstrap2020-06-27T13:54:35ZteorTor launches two requests for authority certificates on first bootstrapWhen tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random director...When tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random directory
We should delay the first scheduled request slightly (5s?) to allow the first request to complete.
This might be as easy as changing the first number in the authority certificate schedule from 0 to 5.
I thought we avoided fetching certificates if another fetch was in progress: clearly that doesn't happen, and maybe we don't want it to, because we don't want to wait a whole 10 seconds for it to timeout.Tor: 0.3.4.x-finalhttps://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.org