Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc

I want to run the standard checks on the 100 fallback directories from April 2016 before we put them in a June? 2016 release candidate.

I bet at least one has changed its fingerprint, IP, or ports, and will need to be removed.

I wonder if we should regenerate the list at that point, or just remove (or update) the broken fallbacks?

I'll decide at the time based on how many are broken.

changed milestone to %Tor: 0.2.8.x-final

added TorCoreTeam201606 actualpoints::0.5 component::core tor/tor milestone::Tor: 0.2.8.x-final must-fix-before-028-stable owner::teor points::0.5 priority::medium resolution::fixed severity::normal status::closed type::enhancement version::tor 0.2.8.2-alpha labels

Trac:
Points: N/A to 0.5

I need another developer to do this with me so someone else understands the fallback selection process.

What skills will that developer need to have? What work will be involved for them?

(I suspect it might be easier to get a volunteer if they knew better what they were getting themselves into.)

Replying to nickm:

What skills will that developer need to have? What work will be involved for them?

(I suspect it might be easier to get a volunteer if they knew better what they were getting themselves into.)

• Run a python script on a reliable, non-tor network connection,
• contact relay operators in response to failures in the script logs,
• edit configuration files based on operator responses.

Please see my branch bug19071-v2 on https://github.com/teor2345/tor.git based on maint-0.2.8.

7e9532b, b15cecd, 69635e4: These commits remove 9 fallbacks from the hard-coded list, because:

• their details have changed (2),
• they are slow to serve consensuses (2),
• they are down permanently (3),
• they have poor uptime (1), or
• they lost the Guard flag (1).

7e9532b, 69635e4: These commits blacklist 7 fallbacks for future releases, because:

• their details have changed (2),
• they are slow to serve consensuses (2), or
• they are down permanently (3).

Some of the whitelist entries are 6 months old now, so losing 10% in 6 months seems like an acceptable rate. (A linear projection would see a loss of 40% of the fallbacks over the 2-year life of a release, at which point 0.4^3 = 6.4% of clients would contact an authority after taking 10 seconds to try 3 bad fallbacks.) As we blacklist unstable fallbacks, we should see better fallback stability in future releases.

0a79e92: This commit modifies the whitelist and blacklist based on from operator emails. We'll use these updated lists for future fallback selection.

4090612: This commit fixes updateFallbackDirs.py to avoid errors when there are no fallbacks.

6ce5366: This commit adds some comments explaining how to test the list of fallbacks before a release.

Trac:
Status: new to needs_review
Actualpoints: N/A to 0.5
Keywords: must-fix-before-028-rc deleted, must-fix-before-028-stable added

Merged!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Please see my branch bug19071-extra on maint-0.2.8 (after the bug19071-v2 merge):

• The way that I commented-out the fallbacks confused stem, which also parses the fallback file.
• I forgot to exclude the fallback that changed its DirPort, which would also confuse stem.
• The operator who added an IPv6 address confirmed it's permanent, so I added it to the whitelist for 0.2.9, but not the list of fallbacks for 0.2.8. (No new info at this stage.)

Trac:
Resolution: fixed to N/A
Status: closed to reopened

merged to 0.2.8 and forward. thanks!

Trac:
Resolution: N/A to fixed
Status: reopened to closed

closed

changed time estimate to 4h

added 4h of time spent

mentioned in issue #19480 (moved)

moved to tpo/core/tor#19071 (closed)

mentioned in issue tpo/core/fallback-scripts#19480 (closed)