Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#15775 closed enhancement (fixed)

Add IPv4 Fallback Directory List to tor, active by default

Reported by: teor Owned by: teor
Priority: High Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.7-alpha
Severity: Major Keywords: 0.2.8.x-triage, tor-dist, 027-triaged-1-in, DoS, SponsorU, 028-triaged, TorCoreTeam201512, MikePerry201512R, tor-dos
Cc: weasel, nickm, ioerror Actual Points: 20
Parent ID: #17158 Points: medium/large
Reviewer: Sponsor: SponsorU

Description (last modified by teor)

weasel writes on tor-dev:

Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.

Reasons why we might want to ship tor with a list of additional places
where clients can find the consensus is that it makes authority
reachability and BW less important.

At the last Tor dev meeting we came up with a list of arbitrary
requirements that nodes should meet to be included in this list.

We want them to have been around and using their current key, address,
and port for a while now (120 days), and have been running, a guard, and
a v2 directory mirror for most of that time.

I have written a script to come up with a list of notes that match our
criteria. It's currently at
https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates

It currently produces
https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list

See https://lists.torproject.org/pipermail/tor-dev/2015-April/008674.html

This file current has 329 entries, and takes up approximately 32kB.
If we hard-coded it in the binary like the authorities, it would increase the binary size by approximately 2% on my platform.

Edit: nickm favours putting it in torrc.defaults
Edit 2: weasel notes torrc.defaults is for package maintainers. Putting it in a list of strings in the code. Much like the authorities.

Do we expect this in by 0.2.7?

Edit: Yes

Do we want to work on a signed file first (#15774)?
(A signed file needs a well-defined threat model and signature verification has to work without access to the authorities or fallback directories.)

Edit: No clear threat model, defer.

Child Tickets

TicketTypeStatusOwnerSummary
#17157defectclosedteorAdd a wiki entry for fallback directories
#17572defectclosedrouter_get_fallback_dirserver_by_digest uses authorities, should use fallbacks
#17576enhancementclosedAdd torrc option to disable default fallback directories

Attachments (6)

torrc.block_authorities (644 bytes) - added by teor 4 years ago.
Torrc which blocks authorities for testing fallback directories
fallback_dirs.inc.20151211 (106.8 KB) - added by teor 4 years ago.
Fallback Directory list from December 2015
fallback_dirs.inc.20160112 (138.5 KB) - added by teor 4 years ago.
Fallback Directory list from January 2016
fallback_dirs.inc (138.5 KB) - added by teor 4 years ago.
Fallback Directory list from January 2016
fallback_dirs.inc.20160406 (55.4 KB) - added by teor 4 years ago.
Fallback Candidates 6 April 2016
extra_fallback_dirs.inc.20160407 (201.1 KB) - added by teor 4 years ago.
Additional Fallback Directory Candidates 7 April 2016

Download all attachments as: .zip

Change History (69)

comment:1 Changed 4 years ago by teor

Status: newneeds_information

comment:2 Changed 4 years ago by teor

Parent ID: #8374

Previous work on this in #8374 wanted IPv6 directory mirrors, but the sample file provided doesn't contain any.

Last edited 4 years ago by teor (previous) (diff)

comment:3 Changed 4 years ago by teor

Parent ID: #8374#15228

#15228 appears to be previous work on this, or a potential duplicate/parent.

comment:4 Changed 4 years ago by teor

Do you want to contact the operator of each directory mirror for permission?

comment:5 Changed 4 years ago by teor

Questions from #15774:

Do we need to wait until a majority of clients update to versions with this change, controlled by a consensus parameter? (Otherwise, using any entry in the file itself would allow clients to effectively be partitioned from the rest of the network by their behaviour.)

While I'm making a list, do we need to modify the existing proposal which describes fallback directories?

Is this change proposed for 0.2.7?
Or all currently supported releases?

Do we need a new configuration option to give the location of the Fallback Directories file(s)?
How should this interact with the existing FallbackDir option?
I propose multiple files and options are all cumulative, but de-duplicated.

comment:6 Changed 4 years ago by nickm

Suggestions for the script: have it also emit (in comments) the name and contact info for each such directory?

comment:7 in reply to:  6 Changed 4 years ago by weasel

Replying to nickm:

Suggestions for the script: have it also emit (in comments) the name and contact info for each such directory?

Updated. Sample output at
https://www.palfrader.org/volatile/fallback-dir/out

comment:8 Changed 4 years ago by teor

Keywords: tor-dist 027-triaged-1-in added
Milestone: Tor: 0.2.8.x-finalTor: 0.2.7.x-final
Owner: set to teor
Priority: normalmajor
Status: needs_informationaccepted
Summary: Add Fallback Directory List to add_default_fallback_dir_servers()Add IPv4 Fallback Directory List to add_default_fallback_dir_servers()

Thanks, weasel.

I am going to proceed with developing this with the following assumptions:

  • We don't want to include IPv6 fallback dirs until #6027 (IPv6 only bootstrap) is fixed
  • We want to distribute the sample output as a separate file, like the geoip files
    • This will need a new config option, say FallbackDirFile
    • We won't hardcode any FallbackDirs in strings in the tor binary (we hardcode the directory authorities in strings in the binary)
  • We want the list of fallback directories to be the union of:
    • All FallbackDir lines in the FallbackDirFile file
    • All FallbackDir lines in the config file
    • With duplicates handled the way current FallbackDir duplicates are handled (ignored? not handled?)

I assume we want this in 0.2.7 from the details in #15228 (which is for fallback directories generally), which I've just copied down to this ticket.

Edit: speling

Last edited 4 years ago by teor (previous) (diff)

comment:9 Changed 4 years ago by teor

Apologies for my presumption/assumptions, Nick:

Would you like the fallback directories in a file (easier to change on a regular basis), or in a string in the code (easier to implement without any extra code apart from the array of strings)?

comment:10 Changed 4 years ago by nickm

I think that having it in a file would make sense to me; it is almost exactly why torrc.defaults exists. Are there any obstacles to that?

comment:11 Changed 4 years ago by teor

No, just a small amount of file loading code, which will work much like torrc.defaults or the geoip files. So I can use them as my example. Then I can access the configured list in add_default_fallback_dir_servers.

I think that the priority should be: (lowest to highest)

  • torrc.defaults FallbackDir lines
  • default FallbackDirFile
  • torrc (including any custom FallbackDirFile)
  • command-line arguments

Generally, I'd expect a union of all those lists, except when it comes to plusses and minuses and the weird option overriding interactions I don't quite understand. I'll trust the config code to do the right thing here.

In a test network, we'll also need to disable the default FallbackDirFile, otherwise test networks could fallback to the public tor network. Which would be weird and unhelpful.

Most test networks are configured to just override the authorities, and I wouldn't want to break that with this change.

comment:12 Changed 4 years ago by teor

Status: acceptedneeds_information

nickm said on IRC:

<nickm> I don't think it needs a new file
<nickm> torrc.defaults should be fine, I think. Right?
<nickm> or rather, I will believe it needs a new file if I know why torrc.defaults won't work. :)

I replied:

<teor> how do we stop a regression to #15642 - how do we know whether the FallbackDir lines have come from the [public tor] defaults list, or a list supplied with a test network?
<teor> Or do we just disable [all] fallback directories in a test network?

Last edited 4 years ago by teor (previous) (diff)

comment:13 Changed 4 years ago by teor

Status: needs_informationaccepted

nickm and I spoke on IRC, and he said that we might actually want to test the fallback directories feature in a test network sometime. That would be prudent.

So, I suggest that we:

  • Stick the default fallback directories in torrc.defaults
    • The final set of FallbackDirs will then be the union of torrc.defaults, torrc, and command-line
  • Create a new FallbackDirsMirrorDefaultDirAuths option set to true by default
  • Only use FallbackDirs if the current authories satisfy FallbackDirsMirrorDefaultDirAuths, that is:
    • If FallbackDirsMirrorDefaultDirAuths is true, and the default directory authorities are being used, use the configured FallbackDirs
    • If FallbackDirsMirrorDefaultDirAuths is false, and custom directory authorities are being used, use the configured FallbackDirs
    • Otherwise, the FallbackDirs don't mirror the authorities, so don't use any FallbackDirs.

Then, anyone wanting to test FallbackDirs in a test network will need to:

  • Set FallbackDirsMirrorDefaultDirAuths to false
  • Disable the default fallback directories in torrc.defaults, or, more likely, disable the use of torrc.defaults entirely on the command-line

I think it's the simplest way to avoid a regression to #15642. Otherwise test networks could fallback to the public tor network.

This avoids an additional FallbackDirFile, and also avoids weird special-casing in the code. It puts an additional configuration burden on test network operators who want to use FallbackDirs (a tiny group), and gets it right by default for everyone else.

Version 0, edited 4 years ago by teor (next)

comment:14 Changed 4 years ago by teor

Description: modified (diff)
Summary: Add IPv4 Fallback Directory List to add_default_fallback_dir_servers()Add IPv4 Fallback Directory List to tor, active by default

Modify title to reflect goal (not implementation)
Add answers to questions asked in enhancement summary.

comment:15 Changed 4 years ago by teor

weasel and I spoke on IRC and torrc.defaults is for package maintainers, not upstream (us).
So I'll create a patch to do the IPv4 portion of this in code, using a script to generate an array of C strings, which is then included in the existing empty array in add_default_fallback_dir_servers().

comment:16 Changed 4 years ago by teor

I have made the following changes to weasel's script:

  • Changed output to C comments and strings
    • removed potentially harmful characters to avoid injection attacks
  • Remove relays that have ever had a BadExit flag
    • No FallbackDirs currently have a BadExit flag
  • Remove relays that are not running a recommended_version (22/353)
    • every FallbackDir reports a version
  • Added IPv6 for #8374
    • 44/353 FallbackDirs have at least one IPv6 address
    • It's not clear what additional work needs to be done for IPv6 directory fetches (#6027), but the ipv6 lines can easily be removed if we decide they're better left out. I think they'd make getting #6027 working easier if they were left in.
  • Implemented stable sorting of secondary orport addresses, so that we always choose the same IP addresses, even if OnionOO changes the order it returns them in (the secondary address order is documented as arbitrary)
    • This affects IPv6 addresses (44/353), and IPv4 addresses where we fall back to a secondary ORPort address because the IP addresses of the DirPort and primary ORPort address don't match (none at present).
  • Implemented last-modified-date to reduce load on OnionOO
    • cache the files on the local filesystem (100MB) and only re-download them when they change

This leaves 331 default FallbackDirs. Is this about what we were expecting?

I'll attach the modified script and the candidate include file to this task after this comment goes through. The patch will include them both.

comment:17 Changed 4 years ago by teor

It doesn't want FallbackDir at the start of the strings. Fixed.

comment:18 Changed 4 years ago by teor

Description: modified (diff)

comment:19 Changed 4 years ago by teor

Status: acceptedneeds_review

I've created a branch with these changes:

Branch: feature15775-fallback
Repository: https://github.com/teor2345/tor.git

This branch includes:

  • scripts/maint/updateFallbackDirs.py, which generates
  • src/or/fallback_dirs.inc, which is included by
  • src/or/config.c (the implementation) and
  • src/test/test_config.c (a unit test)

It also includes the standard changes file.

comment:20 Changed 4 years ago by teor

I have just tested bootstrap with all the authorities blocked in ExcludeNodes, and without any of the authorities blocked.
In both cases, bootstrap works, and the first directory contacted is one of the fallbacks.

Next step: contact operators for opt-in?

comment:21 Changed 4 years ago by teor

This change came through in 0.2.7.1-alpha, do we need to do this for ~300 FallbackDirs as well?

Add DirAuthority lines for default directory authorities to the
output of the "GETINFO config/defaults" command if not already
present. Implements ticket 14840.

comment:22 Changed 4 years ago by teor

It would help to record the relays_published date of each Onionoo document we download, otherwise it will be impossible to trace back from the generated list of fallback directories to the source documents / consensuses.

If different tor developers use documents with the same relays_published date from the same Onionoo instance, they should get the same list of fallback directories. This allows us to cross-check the list of fallback directories.

comment:23 Changed 4 years ago by teor

This fix is now in the branch feature15775-fallback on teor2345 github.

comment:24 Changed 4 years ago by teor

Further fixes in feature15775-fallback-update

comment:25 Changed 4 years ago by teor

For a list of tasks related to IPv4 and IPv6 fallback and bootstrap testing, see:
https://lists.torproject.org/pipermail/tor-relays/2015-June/007109.html

comment:26 Changed 4 years ago by teor

Status: needs_reviewneeds_information

teor's TODO list for this task: do prep work for contacting operators of fallback candidates for opt-in:

[18:04] <teor> Based on https://trac.torproject.org/projects/tor/ticket/15775#comment:20
[18:04] <teor> I think we wanted to contact operators for opt-in
[18:05] <nickm> hm. I think you're right.  Did we have somebody offer to do that?
[18:05] <teor> Does it need to be someone @torproject.org
[18:05] <teor> For the officialness of it all?
[18:08] <teor> I can imagine splitting it into: 1. Demangle emails; 2. Draft letter; 3. Send emails (BCC, of course)
[18:08] <nickm> Yeah, #3 should be from a @tp.o address.
[18:08] <teor> And I could do 1 & 2 at least
[18:08] <nickm> Thanks, that would be awesome
[18:09] <nickm> the letter should explain that it's opt-in, explain what we're asking for, let the know that it means that their IP address shouldn't be very unstable, etc
[18:09] <teor> and the purpose of fallbacks in circumventing auth blocks and spreading load
...
[18:20] <nickm> teor: I'm afraid that the tangle exists in my head as well as in the code.  I think it's fine to mention IPv6 addresses in the email we send out...

comment:27 Changed 4 years ago by teor

Alternately, weasel suggests mailing tor-relays:

[18:38] <weasel> I think a mail to tor-relays and a note in the next tor weekly news that links to the mail ought to suffice.
[18:38] <weasel> basically saying "we intent to list all these relays and all future ones that qualify as fallback" yadada.
[18:39] <weasel> if we wanted to be extra cautious, we could try finding a small number, say 10 or so, and try with those as a first step.
[18:39] <weasel> that could be opt-in without the mails to public places
[18:39] <weasel> and also it'd scale saner.

Updated script in branch feature15775-fallback-update:

  • sort by bandwidth weight (previous sort was by key)
  • take the TOP_N_BY_WEIGHT relays, currently set to 512 as a sanity check

comment:28 Changed 4 years ago by teor

Possible opt-out mechanisms:

  • Manual: operator contacts tor-relays, relay key is added to exclusion list (not yet implemented)
  • Automated: operator configures relay to disable DirPort

comment:29 Changed 4 years ago by teor

To enable opt-in/opt-out, I need to add a whitelist/blacklist feature with IP addresses and/or relay IDs.

In the whitelist, I'd prefer to list both and only include if they are both present in the descriptor.

In the blacklist, I'd prefer to list both and exclude if either is present.

comment:30 Changed 4 years ago by teor

I have updated branch feature15775-fallback-update with gitignore lines for the files generated by the fallback directory update script.

Changed 4 years ago by teor

Attachment: torrc.block_authorities added

Torrc which blocks authorities for testing fallback directories

comment:31 Changed 4 years ago by teor

We want to start with opt-in via email to tor-relays (with proposed list) and operator contact info. This could be drafted by anyone, but needs to be sent from a torproject.org email address.

Operators who opt-in would have their relay fingerprints and IPs added to the list, and be included on the list if both the fingerprint and IP match.

Other considerations, from IRC discussions:

There is a tradeoff between a small list, where a single operator learns about more clients, and a large list, which may become unmanageable. (And it might slow down bootstrap if too many unreliable relays are included.)

Every release containing a list of fallback directories will forever contact those directories on initial bootstrap. We'll need to ensure that the list is large enough that:

  • no one relay / IP gets overwhelming traffic
  • there is always an unblocked relay which can provide an updated consensus (in most cases, the authorities will do this, as long as they are unblocked)

This situation will improve once #15942 (exponential backoff) and #15935 (advisory-only old client disabling) are implemented.

comment:32 Changed 4 years ago by teor

I need to check what tor currently does if a fallback directory fails.
The ideal behaviour is for it to stop contacting failed (fallback) directories, whether tor is running or not.

But I assume it just uses the current directory code.

dgoulet
do you plan to keep a "state file" of those hardcoded IPs meaning if they fail too many times in time period X, you note it down as invalid for Y days?
or it's just, no DirAuth, I'm trying each of them non stop until one replies?

teor
I don't know what the current implementation does with respect to failed fallback directories
I will make a note and check

comment:33 Changed 4 years ago by teor

Keywords: TorCoreTeam201507 added

comment:34 Changed 4 years ago by teor

Keywords: TorCoreTeam201508 added; TorCoreTeam201507 removed

Not going to happen in July

comment:35 Changed 4 years ago by teor

Directory Failures

Directory failures are handled in directory_get_from_dirserver:

When all the dirservers are down, we call(back) directory_all_unreachable and wait for an application connection before we try any more dirservers. (See #16762 for the most recent change to this code.)

The some-dirservers-are-down behaviour seems to work just as well - we ignore them until we've tried all the other ones.

I still need to:

  • Add the whitelist/blacklist feature to the fallback directories list
  • Write a wiki page explaining fallback directories
  • Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
  • Convince someone @ torproject.org to send the email to tor-relays
  • someone @ torproject.org collates responses and adds them to the whitelist
  • Once we have enough whitelist entries, we merge the whitelisted fallback directories into the code

Open Questions:

  • How many relays should we have in the fallback directory list? 100?
    • Modify the code to report the count at the top of the file
    • Modify the code to #error out if we fall below a minimum relay count (100?)
  • Should we adjust weights so no relay has more than 1% (?) of the weight on the list?
    • Modify the code to report the total weight, min, and max proportions at the top of the file
    • Modify the code to adjust weights so that no relay gets more than a maximum proportion of clients (5%?, or 5/(minimum relay count)?)

Dir Auth vs Fallback Weights

  • The dir auths don't have set weights, but the fallback dirs do. Therefore, the auths get weighted 1.0 (the default weight). The fallback weights range from 300K to 300, so the dir auths will hardly ever get contacted (about 1 in 2 million clients, or 1 per day). Is this the desired behaviour? (Edit: fallback directories are prioritised before the authorities. This paragraph is incorrect.)

I need guidance on whether the numbers above are sensible.
But the first step is reporting the actual numbers at the top of the output file.

Last edited 4 years ago by teor (previous) (diff)

comment:36 Changed 4 years ago by teor

Do we also want to add these to GETINFO config/defaults if not already present, or to a separate GETINFO config/fallback_directories?

Split off into #16774.
(If only I'd waited another ticket, the numerology would have been perfect...)

comment:37 Changed 4 years ago by teor

Status: needs_informationneeds_revision

Currently, our top fallback directories are weighted around 2%-3% of the total eligible fallback directory weight. It's possible to reduce that to around 1.6% by redistributing some of the consensus weight across the rest of the relays (or, equivalently, reducing the consensus weight of those relays to some maximum). But making the maximum less than about 1.5% tends to warp the distribution of weights too much.

The updated code is in my teor2345 github branch feature15775-fallback-update-v2.
I still need to implement whitelisting and blacklisting of fallback directories in the script.

Is it OK if a fallback directory sees 1 in 50 client bootstraps (2%)?
(The final figure may change depending on how many relays opt-in to be fallback directories.)
We'd need to widen eligibility criteria a bit to get it down to 1%.

comment:38 Changed 4 years ago by teor

Keywords: DoS SponsorU added

comment:39 Changed 4 years ago by nickm

Keywords: TorCoreTeam201509 added; TorCoreTeam201508 removed

comment:40 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:41 Changed 4 years ago by teor

Keywords: TorCoreTeam201510 added; TorCoreTeam201509 removed

comment:42 Changed 4 years ago by teor

Actual Points: 20
Keywords: 0.2.8.x-triage added
Sponsor: U

comment:43 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:44 Changed 4 years ago by teor

Sponsor: USponsorU

comment:45 Changed 4 years ago by nickm

Points: medium/large

comment:46 Changed 4 years ago by teor

The current behaviour of Fallback Directories is:

  • tor contacts fallback directories *before* the directory authorities
  • tor will try 2 fallback directories, then wait for a minute or two before trying another fallback directory

Do we want to:

  • increase the number of fallbacks that are tried quickly to 3?
  • try the authorities before the fallback directories?
    • for the trial?
    • for the feature release?
  • try N fallback directories quickly, then use the authorities?

comment:47 Changed 4 years ago by teor

Status: needs_revisionneeds_review

Please see my branch feature15775-fallback-v6, which will need to be merged with #4483.

#15775's fallbacks are less reliable than authorities, so we need #4483 to try more connections.

And if #4483 is merged without #15775, it will increase authority load.

comment:48 Changed 4 years ago by teor

Note that there are no fallbacks in the git branch, because no-one has opted-in yet.
Instead, download the attachment fallback_dirs.inc off this patch.

comment:49 Changed 4 years ago by teor

Added feature from prop 220 to script:

  • Target fallback count is 20% of guard count

See feature15775-fallback-v7 on https://github.com/teor2345/tor.git

comment:50 Changed 4 years ago by teor

Severity: Blocker

I had the proposal number wrong in the last commit.
Updated the commit message to say proposal 210, noted that it also covers proposal 206.
See feature15775-fallback-v8.

comment:51 Changed 4 years ago by teor

Severity: BlockerMajor

Ugh, again stung by dgoulet's addition of Severity to Trac.

comment:52 Changed 4 years ago by teor

Keywords: TorCoreTeam201511 added; TorCoreTeam201510 removed

comment:53 Changed 4 years ago by teor

Keywords: TorCoreTeam201512 added

Status Update:

These code changes are ready for review:

  • #17574 - Fallback mirrors should never fetch from fallback mirrors
  • #17576 - Add torrc option to disable default fallback directories

The wiki entry is ready for review:

  • #17157 - Add a wiki entry for fallback directories

The opt-in email / process awaits the code reviews & merges above, and the multi-consensus connection changes in #4483 (for reliability when mirrors go down):

  • #17158 - Run an opt-in process for fallback directories

I'm working on #4483 really soon now.

comment:54 Changed 4 years ago by teor

Keywords: TorCoreTeam201511 removed

This needs #4483, so it will happen in December.

comment:55 Changed 4 years ago by teor

This task is now focused on making clients fetch from fallback directory mirrors. I split off #17709 to make directory downloads happen as follows:

  • authorities generate the consensus
  • FallbackDirs FetchDirInfoExtraEarly
  • Directory Mirrors FetchDirInfoEarly
  • Everything else, including non-directory mirror relays and clients and hidden services and bridges, fetches on a client-like schedule
  • Bridge clients then directory_fetches_dir_info_later()

comment:56 Changed 4 years ago by mikeperry

Keywords: MikePerry201512R added

comment:57 Changed 4 years ago by teor

I've updated the fallback directory candidate lists with IPv6 ORPorts as (soon to be) implemented in #17281.

Edit: I've added the changes as additional commits on feature15775-fallback-v9

Last edited 4 years ago by teor (previous) (diff)

comment:58 Changed 4 years ago by nickm

The C looks perfectly fine.

The fallback_dirs.inc file really needs to be listed in src/or/include.am's HEADERS or EXTRA_DIST or something.

At first glance the Python is plausible, and IMO that's good enough.

If you make me a nice squashed-down branch version of this, that's good enough to merge IMO.

comment:59 in reply to:  58 Changed 4 years ago by teor

Replying to nickm:

The C looks perfectly fine.

The fallback_dirs.inc file really needs to be listed in src/or/include.am's HEADERS or EXTRA_DIST or something.

I put it in ORHEADERS, like ciphers.inc is in COMMONHEADERS in src/common/include.am.

At first glance the Python is plausible, and IMO that's good enough.

If you make me a nice squashed-down branch version of this, that's good enough to merge IMO.

I made the above change, updated the whitelist and blacklist comments to include IPv6 ORPorts (oops), and removed some test data in comments in the whitelist and blacklist.

I squashed it down to a single commit in feature15775-fallback-v9-squashed.
(I can't see the point of multiple commits for this script.)

comment:60 Changed 4 years ago by nickm

great; merged it! (Can't close because of open child tickets.)

comment:61 Changed 4 years ago by teor

Parent ID: #15228#17158
Resolution: fixed
Status: needs_reviewclosed

With #17327 and #15775 merged, we can now run an opt-in fallback directories trial in #17158. We can generate a list of fallbacks for each release using scripts/maint/updateFallbackDirs.py and the whitelist/blacklist from that trial.

(Clients will use IPv4 fallbacks immediately, but they won't use IPv6 authorities or fallbacks until #17840 is implemented.)

comment:62 Changed 4 years ago by teor

(Deleted the updateFallbackDirs.py attachment, as people are using it instead of the latest version in the tor git repository.)

Changed 4 years ago by teor

Attachment: fallback_dirs.inc.20151211 added

Fallback Directory list from December 2015

Changed 4 years ago by teor

Attachment: fallback_dirs.inc.20160112 added

Fallback Directory list from January 2016

Changed 4 years ago by teor

Attachment: fallback_dirs.inc added

Fallback Directory list from January 2016

Changed 4 years ago by teor

Attachment: fallback_dirs.inc.20160406 added

Fallback Candidates 6 April 2016

Changed 4 years ago by teor

Additional Fallback Directory Candidates 7 April 2016

comment:63 Changed 4 years ago by mikeperry

Keywords: tor-dos added

Canonicalize dos tag to tor-dos

Note: See TracTickets for help on using tickets.