Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:58:30Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19810Could high-bandwidth ORPort-only relays be fallbacks?2020-06-27T13:58:30ZteorCould high-bandwidth ORPort-only relays be fallbacks?In 0.2.8, relays automatically support begindir over ORPort, even if they don't have a DirPort.
I wonder if we're missing out on (m)any high-bandwidth relays by excluding relays without a DirPort. That said, we wouldn't want too many, b...In 0.2.8, relays automatically support begindir over ORPort, even if they don't have a DirPort.
I wonder if we're missing out on (m)any high-bandwidth relays by excluding relays without a DirPort. That said, we wouldn't want too many, because relays still use the DirPort to bootstrap off fallbacks. (But if the fallback only has an ORPort, the relay will use that.)
We'd need to make the following changes for this to happen:
* modify the DirPort requirement during fallback selection to check for either a DirPort, or declared begindir support in the descriptor
* make a DirPort optional for configured FallbackDirs in Tor
* this may be as simple as setting the DirPort to 0, and disabling the validation. The rest of the code might just work, because it ignores 0 DirPorts
* test, test, testTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19782Remove a fallback directory in 0.2.82020-06-27T13:58:31ZteorRemove a fallback directory in 0.2.8An operator just told me they are taking down their fallback directory. So I need to comment it out in the 0.2.8 fallback_dirs.inc file, and move it from the whitelist to the blacklist.
The fingerprint is 08DC0F3C6E3D9C527C1FC8745D35DD1...An operator just told me they are taking down their fallback directory. So I need to comment it out in the 0.2.8 fallback_dirs.inc file, and move it from the whitelist to the blacklist.
The fingerprint is 08DC0F3C6E3D9C527C1FC8745D35DD1B0DE1875D.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19610IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks2020-11-04T14:18:56ZteorIPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacksWhen an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback di...When an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback directories, fetching ~7500/500 = 15 sets of descriptors from 15 of the 25 IPv6 fallbacks.
We should improve this behaviour somehow, to avoid overloading the fallbacks. One simple way of doing this is selecting 200 fallbacks for 0.2.9 in legacy/trac#18828.
It's worth noting that this extra load only happens on bootstrap, when there are no cached microdescriptors. If an IPv6-only client has any IPv6 microdescriptors that match the current consensus, it will use those relays instead.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19608IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc2020-06-27T13:58:37ZteorIPv6-only clients can't fetch microdescriptors on 0.2.8.5-rcThere's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* b...There's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* but it's a consensus, so IPv6-only clients try to use it to find an IPv6 relay, and fail
A solution is to teach IPv6-only clients to get (at least some of) their descriptors from the fallback directories, at least until they have some IPv6 microdescriptors. Perhaps this should happen automatically when the entire consensus fails, but for some reason it doesn't.
I have no idea how we didn't catch this during testing - perhaps there were always cached descriptors? Perhaps we broke falling back to the fallbacks for descriptors?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18812[warn] Tried connecting to router at 81.7.17.171:443, but identity key was no...2020-06-27T13:59:14ZRoger Dingledine[warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
...I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 13 03:17:50.620 [warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
Apr 13 03:17:52.147 [notice] Bootstrapped 40%: Loading authority key certs
[...]
```
So I think everything is going according to plan (cool, I even used a fallback dir!), except my fallback dir seems to have changed its key since it went into fallback_dirs.inc.
Maybe it isn't so reliably stable after all? :) :/
I wonder if we should consider a) doing periodic full checks of the fallback relays, to catch issues like this one preemptively, and then b) making the warning less scary for normal users.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40651Generate new fallbackdir list for 0.4.7.9 release2022-08-03T11:57:55ZRoger DingledineGenerate new fallbackdir list for 0.4.7.9 releaseWe're at about 1/3 failures on the current fallbackdir list. I see that @dgoulet has just requested the directory authorities to prepare for the 0.4.7.9 release. And I think there is a new Tor Browser coming out in August sometime.
All ...We're at about 1/3 failures on the current fallbackdir list. I see that @dgoulet has just requested the directory authorities to prepare for the 0.4.7.9 release. And I think there is a new Tor Browser coming out in August sometime.
All of these are great reasons to do a refresh of the fallbackdir list for these upcoming releases. (Releases plural, since it seems smart to put the refreshed list into 0.4.5 and 0.4.6 too, so LTS Tor users can have their Tor work too.)
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/40447Regenerate fallbackdir list for August 2021 releases2021-08-11T14:05:28ZDavid Gouletdgoulet@torproject.orgRegenerate fallbackdir list for August 2021 releasesThis is simply to track the new fallbackdir list's MR.This is simply to track the new fallbackdir list's MR.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40069Remove Digitalcourage3 relays from fallbackdir list2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orgRemove Digitalcourage3 relays from fallbackdir listSomehow they ended up in the list and they were not suppose to. The operator just emailed me about it.
Removal is:
```
9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D
ADB2C26629643DBB9F8FE0096E7D16F9414B4F8D
C2AAB088555850FC434E68943F55107204...Somehow they ended up in the list and they were not suppose to. The operator just emailed me about it.
Removal is:
```
9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D
ADB2C26629643DBB9F8FE0096E7D16F9414B4F8D
C2AAB088555850FC434E68943F551072042B85F1
```David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26688Parse ed25519 IDs in the authority and fallback lists2021-09-16T14:29:03ZteorParse ed25519 IDs in the authority and fallback listshttps://gitlab.torproject.org/tpo/core/tor/-/issues/26685Add ed25519 id support for the hard-coded fallback and authority lists2022-06-16T16:11:23ZteorAdd ed25519 id support for the hard-coded fallback and authority listsThis is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.This is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.https://gitlab.torproject.org/tpo/core/tor/-/issues/24839Add a torrc option and descriptor line to opt-in as a FallbackDir2022-03-22T13:28:46ZteorAdd a torrc option and descriptor line to opt-in as a FallbackDirThis needs:
* a proposal and a design
* a patch to dir-spec.txt
* a patch to the tor man page
* a tor code patch
* an updateFallbackDirs.py code patch
* a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]
Here's a quick sketch of ...This needs:
* a proposal and a design
* a patch to dir-spec.txt
* a patch to the tor man page
* a tor code patch
* an updateFallbackDirs.py code patch
* a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]
Here's a quick sketch of a design:
1. Relay operators set `OfferFallbackDir 1` to offer their relay as a potential FallbackDir.
2. Relays with this option set put `offer-fallback-dir` in their descriptors
3. updateFallbackDirs.py loads relay fingerprints with `offer-fallback-dir`, and from the legacy offer list
4. updateFallbackDirs.py does stability checks, and generates the fallback listhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22760Fix extra-info flags on fallbacks2021-09-16T14:31:59ZteorFix extra-info flags on fallbacksSee the first comment for details.See the first comment for details.https://gitlab.torproject.org/tpo/core/tor/-/issues/18481Allow the fallback directory schedules to be changed outside a test network2021-09-16T14:34:12ZteorAllow the fallback directory schedules to be changed outside a test networkIn legacy/trac#4483, I made the additional schedules TestingTorNetwork. But, if it turns out they need tuning, we want to be able to change them in the default torrc in a Tor Browser release.
So they need to be turned into non-testing t...In legacy/trac#4483, I made the additional schedules TestingTorNetwork. But, if it turns out they need tuning, we want to be able to change them in the default torrc in a Tor Browser release.
So they need to be turned into non-testing torrc options, and the testing values moved to the common chutney template.
This also involves carefully sanity checking any user-supplied values to these options.https://gitlab.torproject.org/tpo/core/tor/-/issues/18084Use the same fallback directory mirror to bootstrap2022-06-17T14:30:58ZteorUse the same fallback directory mirror to bootstrapIf Tor always tries to use the same fallback directory mirror to bootstrap (when the consensus expires because Tor isn't used), fewer servers learn about Tor clients, and a Tor client is less likely to download from a bad fallback direct...If Tor always tries to use the same fallback directory mirror to bootstrap (when the consensus expires because Tor isn't used), fewer servers learn about Tor clients, and a Tor client is less likely to download from a bad fallback directory mirror.
This is low priority, as most Tor clients only bootstrap once [citation needed].https://gitlab.torproject.org/tpo/core/tor/-/issues/7798Use directory guards even when consensus isn't live2021-06-18T18:21:27ZNick MathewsonUse directory guards even when consensus isn't liveOur initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP a...Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.