Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-08-03T11:57:55Zhttps://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/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/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/40493fallbackdirs: Update list for October 2021 releases2021-11-14T12:41:19ZDavid Gouletdgoulet@torproject.orgfallbackdirs: Update list for October 2021 releasesWe are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.We are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/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/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/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/20194Add "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.md2021-07-22T16:23:16ZteorAdd "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.mdWhen we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update th...When we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update the list of fallback directory mirrors using the instructions in: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30955Update the fallback entry in the man page2021-07-22T16:19:44ZteorUpdate the fallback entry in the man page"FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport;..."FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport; clients ignore this in favor of the specified "orport=" value."
"Clients always use the orport. Relays prefer the dirport, but will use the orport in some circumstances."
Add something to the FallbackDir entry talking about how the DirPort is used by the checking script?Tor: 0.4.2.x-finalteorteorhttps://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.https://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/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/19989Tor fails to bootstrap with an Exit as EntryNode2020-07-27T19:41:51ZteorTor fails to bootstrap with an Exit as EntryNodeWhen I try to run tor with EntryNodes x (where x is a single Exit relay), it hangs at:
```
Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 26 00:51:57.000 [notice] I learned some more directory informatio...When I try to run tor with EntryNodes x (where x is a single Exit relay), it hangs at:
```
Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 26 00:51:57.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6973, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
Aug 26 00:51:58.000 [notice] Bootstrapped 50%: Loading relay descriptors
```
~~This issue might prevent us from switching to one guard in future releases.~~
This issue likely makes Exits useless as fallback directories for IPv6-only microdescriptor clients (legacy/trac#19608).
I can reproduce this issue on 0.2.9.2-alpha-dev, 0.2.8.{6,7}, maint-0.2.7, maint-0.2.6 using the following command:
```
src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40061Rebuild fallbackdir list 20202020-07-23T14:11:07ZDavid Gouletdgoulet@torproject.orgRebuild fallbackdir list 2020We ran the call for action: fallback-scripts#30971
This ticket is to merge the new list in `fallback_dirs.inc`
This needs to be backported down to 035.We ran the call for action: fallback-scripts#30971
This ticket is to merge the new list in `fallback_dirs.inc`
This needs to be backported down to 035.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/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/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/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: unspecified