Allow Fallback Directories with no DirPort

[teor]

In #12538, we made almost every relay support begindir-style directory fetches. In #18483, we made clients never use DirPorts. Both of these features are scheduled for 0.2.8.

Eventually, we can allow fallback directories with no DirPort.
(Perhaps this works already with a zero DirPort?)
If we implement #7798, we might want this feature, but only for directory guards in the state file.

If we want to include fallback directories with no DirPort in the default fallback list, we will need to make some some changes to the fallback directory checks in scripts/maint/updateFallbackDirs.py. In particular, stem can't do begindir, so it will be harder to verify these fallback directories have connectivity and support begindir. So maybe we should require a DirPort for fallback directories for the moment.

[atagar]

Yup. If somebody wanted to write a Stem patch so it could retrieve directory information from the ORPort I'd love to have that. Haven't a clue how difficult it would be though.

[teor]

#19810 is a duplicate of this. It had the following additional info:

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, test

[teor]

Milestone renamed

[nickm]

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

[nickm]

Remove an old triaging keyword.

[atagar]

For what it's worth stem's descriptor downloader *doesn't* use fallback directories because they lack extrainfo descriptors...

​https://gitweb.torproject.org/stem.git/commit/?id=758f632

This is fine. Tor doesn't need it (nor does it need the DirPort). However, if you want the fallbacks to relieve DirAuth load from other sources such as stem then these are both issues.

[teor]

Replying to atagar:

For what it's worth stem's descriptor downloader *doesn't* use fallback directories because they lack extrainfo descriptors...

​https://gitweb.torproject.org/stem.git/commit/?id=758f632

This is fine. Tor doesn't need it (nor does it need the DirPort). However, if you want the fallbacks to relieve DirAuth load from other sources such as stem then these are both issues.

Ah, but all stem needs to know is *whether* the fallback has a DirPort and caches extra-info, right? I opened #22760 to implement this.

[atagar]

Yup! Many thanks teor. :P

[teor]

We might do this in 0.3.4 if stem implements ORPort support by then. See #18856.
This will require a fallback script change, and a Tor change.

And we will have to think about whether we want to backport the tor change.
(We could backport a minimal change that ignores fallbacks with no DirPort.)

[nickm]

Per our triage process, these tickets are pending removal from 0.3.4.

[nickm]

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

[teor]

This ticket is not part of the minimal fallback rebuild, and it depends on stem's ORPort support stabilising.
Also, I would do fallback opt-ins in relay torrcs (#24839) before this ticket.

[teor]

After #27914, fallback-scripts is its own repository. Fallback changes are no longer tied to Tor releases.