Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:20:30Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24876Directory Authorities should test reachability of relays in their family2020-06-13T15:20:30ZteorDirectory Authorities should test reachability of relays in their familySebastian reported on #tor-dev that directory authorities can't set MyFamily, because it makes the relays in the family get marked as not Running.
I'm not sure if this restriction is in the connecting code on authorities or relays, or t...Sebastian reported on #tor-dev that directory authorities can't set MyFamily, because it makes the relays in the family get marked as not Running.
I'm not sure if this restriction is in the connecting code on authorities or relays, or the accepting code on relays.
If it's on the connecting side, we can disable it on authorities.
If it is in the accepting code on relays, maybe we need to keep it as a defence in depth measure. But we could disable it for authority IP addresses. (It wouldn't work with multiple authority IPs or OutboundBindAddress, but that's getting obscure.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24864directory authorities take a while to update relays' Tor versions because the...2020-06-13T18:02:17Zcypherpunksdirectory authorities take a while to update relays' Tor versions because they use old descriptors for votescopy from
https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
Hi,
the goal of this email is to avoid a false positive warning for relay operators
on atlas but the root cause might be in core tor.
background:
I re...copy from
https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
Hi,
the goal of this email is to avoid a false positive warning for relay operators
on atlas but the root cause might be in core tor.
background:
I really liked when irl added the big red warning to atlas when a tor relay
runs an outdated (aka not running a "recommended") tor version
because it actually triggered operators to upgrade, an important step toward a more healthy network.
The problem is: This big red banner on atlas has false-positives which confuses operators [0].
Originally this has been an onionoo bug which
has been fixed in v1.8.0, but it happens again and Karsten had the feeling
that tor dir auths do not update the version information of a relay after it
upgraded (and uploaded a new descriptor). I looked into one example and can confirm what Karsten suggested [1].
Let me show you that example of FP 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
Data has been provided by Karsten and is available here: [2].
That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his first
descriptor with 0.3.0.13 on:
```
2018-01-09 10:14:00,server,,0.3.0.13
```
except for bastet dir auths did not care and still said this relay runs
0.3.0.10:
```
2018-01-09 11:00:00,consensus,,0.3.0.10
2018-01-09 11:00:00,vote,bastet,0.3.0.13 <<<< note
2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
2018-01-09 11:00:00,vote,dizum,0.3.0.10
2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 11:00:00,vote,longclaw,0.3.0.10
2018-01-09 11:00:00,vote,maatuska,0.3.0.10
2018-01-09 11:00:00,vote,moria1,0.3.0.10
2018-01-09 11:00:00,vote,tor26,0.3.0.10
2018-01-09 12:00:00,consensus,,0.3.0.10
2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<<<<<
2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
2018-01-09 12:00:00,vote,dizum,0.3.0.10
2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 12:00:00,vote,longclaw,0.3.0.10
2018-01-09 12:00:00,vote,maatuska,0.3.0.10
2018-01-09 12:00:00,vote,moria1,0.3.0.10
2018-01-09 12:00:00,vote,tor26,0.3.0.10
```
even 6 hours later this is unchanged.
Then the operator upgraded from 0.3.0.13 to 0.3.1.9
and uploaded his first descriptor:
```
2018-01-09 16:39:01,server,,0.3.1.9
```
this remained "unnoticed" by all dir auths until
longclaw voted for the new version:
```
2018-01-09 23:00:00,consensus,,0.3.0.10
2018-01-09 23:00:00,vote,bastet,0.3.0.10
2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
2018-01-09 23:00:00,vote,dizum,0.3.0.10
2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <<<<<
2018-01-09 23:00:00,vote,maatuska,0.3.0.10
2018-01-09 23:00:00,vote,moria1,0.3.0.10
2018-01-09 23:00:00,vote,tor26,0.3.0.10
```
On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
v0.3.1.9 and almost all dir auths agreed immediately:
```
2018-01-10 02:38:07,server,,0.3.1.9
2018-01-10 03:00:00,consensus,,0.3.1.9
2018-01-10 03:00:00,vote,bastet,0.3.0.10
2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
2018-01-10 03:00:00,vote,dizum,0.3.1.9
2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
2018-01-10 03:00:00,vote,longclaw,0.3.1.9
2018-01-10 03:00:00,vote,maatuska,0.3.1.9
2018-01-10 03:00:00,vote,moria1,0.3.1.9
2018-01-10 03:00:00,vote,tor26,0.3.1.9
```
So it took the operator 17 hours to convince enough
dir auths that he upgraded.
I can see multiple reasons why this can make sense (as the tor version
is actually not that relevant consensus data) but maybe it was
not clear what the side effects of not updating that field are.
While I believe there is still another onionoo issue,
this should also be improved.
Thoughts?
[0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
[1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
[2] https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488-relay-versions.csv.gz
#24862 aims to help track and debug this.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24854Extract the authority list from config.c2020-06-13T15:20:14ZteorExtract the authority list from config.cThere is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.in...There is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.inc.
We will need to implement two branches for backporting:
* a branch on maint-0.2.9 for 0.2.9 and later. It has IPv6 addresses.
* ~~a branch on maint-0.2.5 for 0.2.5. It has no IPv6 addresses.~~
(Then, after we have moved it into a separate file, we want to automatically generate the file, in a new format. See the rest of the children of #24818.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24852update the fallback script to generate the new format2020-06-13T15:20:12Zteorupdate the fallback script to generate the new format* increment the version
* modify the structure of the current list, but not the content
* check that all supported Tor versions (0.2.9 and later) can parse the list (existing unit tests)* increment the version
* modify the structure of the current list, but not the content
* check that all supported Tor versions (0.2.9 and later) can parse the list (existing unit tests)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24851create a script that generates the authority format from the authorities in t...2020-06-13T16:06:25Zteorcreate a script that generates the authority format from the authorities in the current consensusWe need to make sure we also:
* apply address overrides
* make sure the details match the current list
* check that all supported Tor versions can parse the list (existing unit tests)We need to make sure we also:
* apply address overrides
* make sure the details match the current list
* check that all supported Tor versions can parse the list (existing unit tests)https://gitlab.torproject.org/legacy/trac/-/issues/24818Make the hard-coded authorities into a separate include file with a standard ...2020-06-13T15:19:59ZteorMake the hard-coded authorities into a separate include file with a standard formatIn #24742, we created a specification for a standard fallback file format. We could use this for a list of hard-coded authorities as well.
This would make it easier for stem, metrics lib, external applications, and custom tor implementa...In #24742, we created a specification for a standard fallback file format. We could use this for a list of hard-coded authorities as well.
This would make it easier for stem, metrics lib, external applications, and custom tor implementations to track the latest authority changes.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-06-13T15:26:54ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of #15518.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24456Figure out what to do with the guardfraction feature2020-06-13T15:18:10ZGeorge KadianakisFigure out what to do with the guardfraction featureGuardfraction code is still around the codebase: `guard_get_guardfraction_bandwidth()`, `should_apply_guardfraction()`, `routerstatus_parse_guardfraction()`, `guardfraction_line_apply()`, `guardfraction_file_parse_guard_line()`, `dirserv...Guardfraction code is still around the codebase: `guard_get_guardfraction_bandwidth()`, `should_apply_guardfraction()`, `routerstatus_parse_guardfraction()`, `guardfraction_line_apply()`, `guardfraction_file_parse_guard_line()`, `dirserv_read_guardfraction_file_from_str()`, `compute_weighted_bandwidths()`. Also AFAIK some dirauths are still running the guardfraction python script.
Unfortunately, guardfraction code is still broken because of #16255 and possibly other unknown bugs. Hence, guardfraction support is disabled in the dirauths and all that code is currently useless.
My current plan here is to remove the guardfraction code from the Tor codebase, since fixing it and maintaining it as a PITA that I don't want to sign up for and we probably don't need it as much as we thought we did (see comment:36:ticket:16255).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24394add ipv6 dirauth address2020-06-13T15:17:54ZStefani Banerianadd ipv6 dirauth address
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list message
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list messageTor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2020-06-13T15:17:53ZteorClients 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 #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 #15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24377Warn about networkstatus_compute_consensus() breakage in all the functions it...2020-06-13T15:17:50ZteorWarn about networkstatus_compute_consensus() breakage in all the functions it callsnetworkstatus_compute_consensus() says:
```
* <strong>WATCH OUT</strong>: You need to think before you change the
* behavior of this function, or of the functions it calls! If some
* authorities compute the consensus with a different ...networkstatus_compute_consensus() says:
```
* <strong>WATCH OUT</strong>: You need to think before you change the
* behavior of this function, or of the functions it calls! If some
* authorities compute the consensus with a different algorithm than
* others, they will not reach the same result, and they will not all
* sign the same thing! If you really need to change the algorithm
* here, you should allocate a new "consensus_method" for the new
* behavior, and make the new behavior conditional on a new-enough
* consensus_method.
```
But its call graph is somewhat obscure, and it isn't always clear when a function is called by some tree of functions called by networkstatus_compute_consensus().
Let's add a summary comment to each function that affects networkstatus_compute_consensus() output. And let's try to do this in an automated fashion.
Maybe out modularity proposal is the best way to handle this?
(Then a module-level comment would suffice.)
But would consensus-affecting functions be a good candidate for a module?
(Or two modules: authority-only and shared.)
(We already have chutney "mixed" targets that pick up the most obvious breakage. But they can't test everything.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24366compare_vote_rs() could check more fields for better SHA1 collision resistance2020-06-13T15:17:44Zteorcompare_vote_rs() could check more fields for better SHA1 collision resistanceIf someone submits descriptors with the same SHA1 hashes, compare_vote_rs() checks a few fields to make sure they are really the same.
We should make sure there is some way of checking all (most?) of the fields. And we should compare ne...If someone submits descriptors with the same SHA1 hashes, compare_vote_rs() checks a few fields to make sure they are really the same.
We should make sure there is some way of checking all (most?) of the fields. And we should compare new fields when they are added to [vote_]routerstatus_t. But we can't just use a binary comparison, because some of the fields are pointers.
Do we need a new consensus method to add extra tie-breakers?
Here are the fields from vote_routerstatus_t and routerstatus_t, in rough order of size/flexibility/collision-usefulness:
Comparing these is probably necessary, they have 128+ bits of entropy:
* version
* protocols
* exitsummary
* ed25519_id
* ipv6_addr
Comparing these might not be necessary, they only have a few bits:
* ipv6_orport
* measured_bw_kb / bandwidth_kb ?
* guardfraction_percentage
I'm not sure if comparing these is necessary, they probably don't have enough bits to lead to a collision:
* flags / is_x (x is a flag name)
* supports_x (x is a feature name)
* has_guardfraction
* has_measured_bw
* has_ed25519_listing
* has_bandwidth
* has_exitsummary
This is a bug in Tor 0.2.0.3-alpha, which introduced this tie-breaking code. (Or in all the versions since then that added extra fields to [vote_]routerstatus_t, but didn't add them to the tie-breakers.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24338DirAuths that have IPv6 addresses don't include them in their vote on themself2020-06-13T15:17:36ZTom 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/legacy/trac/-/issues/24186vote: Voting schedule is not updated before voting2020-06-13T15:17:07ZDavid Gouletdgoulet@torproject.orgvote: Voting schedule is not updated before votingCommit e67f4441eb2646368e3e7cb1bcee403667b786f0 introduced a safeguard in `dirvote_get_next_valid_after_time()` in order to recalculate the voting schedule if it is called before it was initialized.
Turns out that it is actually called ...Commit e67f4441eb2646368e3e7cb1bcee403667b786f0 introduced a safeguard in `dirvote_get_next_valid_after_time()` in order to recalculate the voting schedule if it is called before it was initialized.
Turns out that it is actually called very early for a directory authority with `sr_init()` thus the voting schedule is first initialized through that safeguard.
That made the following check in `dirvote_act()` not work so the voting schedule is never recalculated using the `now` that we are about to use to vote with:
```
if (!voting_schedule.voting_starts) {
...
dirvote_recalculate_timing(options, now);
}
```
This lead to warnings such as (snipping some lines):
```
Nov 08 11:58:19.169 [info] Choosing expected valid-after time as 2017-11-08 16:58:20: consensus_set=0, interval=5
[...]
Nov 08 11:58:20.173 [notice] Time to vote.
[...]
Nov 08 11:58:20.175 [notice] Choosing valid-after time in vote as 2017-11-08 16:58:25: consensus_set=0, last_interval=5
Nov 08 11:58:20.181 [warn] Rejecting vote from 127.0.0.1 with valid-after time of 2017-11-08 16:58:25; we were expecting 2017-11-08 16:58:20
Nov 08 11:58:20.181 [warn] Couldn't store my own vote! (I told myself, 'Bad valid-after time'.)
```
Voting schedule object was set at "11:58:19" which made a valid_after time to "11:58:20" but we voted at "11:58:20" without updating that schedule so we ended up computing a valid_after = "11:58:25" in the vote but not in the voting schedule.
I *think* the fix here is to always recalculate our voting schedule when we are about to vote to use the "now" value maybe?Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24103Remove the NoEdConsensus flag2020-06-13T15:16:43ZteorRemove the NoEdConsensus flagWhen we have ed keys in the consensus, we won't need this flag any more.
And so we won't need to write any code to actually use it in relays or clients.When we have ed keys in the consensus, we won't need this flag any more.
And so we won't need to write any code to actually use it in relays or clients.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23910Add bastet to the list of default authorities2020-06-13T15:16:06ZDavid Gouletdgoulet@torproject.orgAdd bastet to the list of default authorities`bastet` is the new directory authority run by stefani.
It is now trusted in the Thu Oct 19th 2017 20:00:00 UTC consensus.
https://collector.torproject.org/recent/relay-descriptors/consensuses/2017-10-19-20-00-00-consensus
The dirauth...`bastet` is the new directory authority run by stefani.
It is now trusted in the Thu Oct 19th 2017 20:00:00 UTC consensus.
https://collector.torproject.org/recent/relay-descriptors/consensuses/2017-10-19-20-00-00-consensus
The dirauth-conf.git `DirServer` line is:
```
DirServer bastet orport=443 v3ident=27102BC123E7AF1D4741AE047E160C91ADC76B21 204.13.164.118:80 24E2 F139 121D 4394 C54B 5BCC 368B 3B41 1857 C413
```Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23254BridgeAuth offline key mode seems broken2020-06-13T15:12:45ZIsis LovecruftBridgeAuth offline key mode seems brokenYesterday I renewed the signing keys for the Bifröst (see #23253) but the machine still couldn't join the network. This is my best understanding of the problem, which I repeatedly witnessed trying to fix the machine:
```
19:29 ...Yesterday I renewed the signing keys for the Bifröst (see #23253) but the machine still couldn't join the network. This is my best understanding of the problem, which I repeatedly witnessed trying to fix the machine:
```
19:29 isis+ | so it seems the bridgeauth was still down, even though i "fixed" the expired signing keys yesterday
19:30 isis+ | which apparently it doesn't even need signing keys, so why i wasted an afternoon fixing it when i'm supposed to be preparing for a talk is a bit annoying
19:30 isis+ | but nobody runs this code so hey, what should i expect
19:31 isis+ | this time it was not in the consensus because the other dirauths didn't recognise it because it "had new keys"
19:33 isis+ | which, upon inspection, seemed to mean that, even though i have always specified "OfflineKeys 1", the bridgeauth somehow generated a ed25519_master_id_secret_key (??) however it kept the old
ed25519_master_id_public_key, and then it used this new ed25519_master_id_secret_key to sign the ed25519_signing_cert (which had already been signed by the real ed25519_master_id_secret_key which
is kept…
19:33 isis+ | …offline)
19:33 isis+ | this resulted in a complete clusterfuck of mismatched and mis-signed keys
19:35 isis+ | and even though the ed25519_signing_cert was already generated offline (afaict correctly) it was the bridgeauth's insistence on making a new ed25519_master_id_secret_key that was causing the
problem
19:37 isis+ | the only way i could think of, without fixing all these probable bugs, to fix this, was to go back to the offline machine and use the correct ed25519_master_id_secret_key to regenerate new
keypairs with "OfflineKeys 0" and no signing_cert expiration, and then transfer all the keys to lapsedpacifist
19:37 isis+ | so the bridgeauth no longer has "offline keys" but i guess it never really did, and it wouldn't even be useful even if it could
```
Sorry, I'll clean up the IRC paste mess into a proper description later, I seriously have to go prepare my slides for my talk. :(Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23253BridgeAuth goes offline when it has an expired ed25519_signing_cert2020-06-13T15:12:45ZIsis LovecruftBridgeAuth goes offline when it has an expired ed25519_signing_certHowever, Roger says in IRC that the BridgeAuth doesn't use (or shouldn't be using) this key, since it's only for v3 DirAuths.However, Roger says in IRC that the BridgeAuth doesn't use (or shouldn't be using) this key, since it's only for v3 DirAuths.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23170Include ed25519 relay id keys in the consensus2020-06-13T15:18:03ZGeorge KadianakisInclude ed25519 relay id keys in the consensusProposal 220 specifies how ed25519 id keys should be encoded in the consensus, but the change has not been implemented yet.
This is a problem in the next gen HS design, since prop224 specifies that the HSDir hash ring should be formed u...Proposal 220 specifies how ed25519 id keys should be encoded in the consensus, but the change has not been implemented yet.
This is a problem in the next gen HS design, since prop224 specifies that the HSDir hash ring should be formed using the relay ed25519 keys, but these are not in the consensus which means that the service and the clients need to fetch all the microdescriptors before getting an accurate picture of the hash ring. Uploading or fetching HS descriptors without having all the relay microdescriptors can lead to hash ring desynch and reachability failures.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22820Give the Exit flag to Exits that use the secure IRC port 66972020-06-13T15:14:35ZteorGive the Exit flag to Exits that use the secure IRC port 6697Igor Mitrofano suggests that the Exit flag should be given to relays that allow exiting to the default secure IRC port 6697.
From tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2017-July/012585.html
The existing policy i...Igor Mitrofano suggests that the Exit flag should be given to relays that allow exiting to the default secure IRC port 6697.
From tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2017-July/012585.html
The existing policy is "two ports from [80, 443, 6667]", or these options:
* 80, 443
* 80, 6667
* 443, 6667
We would change to "two ports from [80, 443, 6667-OR-6697]", adding these options:
* 80, 6697
* 443, 6697
We don't need a new consensus method for this, because the way Exit flags are combined stays as majority vote.Tor: unspecified