[tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-dirauth, tor-guard, review-      |  Actual Points:
  group-32, review-group-33                      |
Parent ID:                                       |         Points:  2
 Reviewer:  mikeperry                            |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:14 mikeperry]:
 > After catching up on the related bugs (#13297, #16255), it seems like
 the reason this is being killed is because of the lack of unit test
 support to take in all inputs for a consensus (votes, bw auth files,
 guardfraction files) and produce a consensus, and then examine that
 consensus for expected results for both values and client usage. If we had
 that, it would be much easier to verify that the fix in #16255 is
 sufficient, right?
 >
 > If that is true, then I would rather obsolete the torrc options for now
 without removing any code, and file a ticket for better consensus testing
 support. There have been several other path selection tickets where I
 wished I just had a full consensus to check behavior against, rather than
 cobbling together a mock or tiny chutney network...
 >
 > Once we have such a testing mechanism, it will be much easier to bring
 this code back with torrc options like GuardFractionV2File (since in
 #16255 we already discussed changing the format slightly), rather than
 ripping it out and starting over completely from scratch. We need the
 guardfraction feature (or something like it) less since we have backed off
 from infinite guard lifetimes, but I don't think the need is now zero.

 We opted for removing the code instead of just obsoleting the torrc
 options so that we also simplify the codebase as a result, given that the
 feature has been unused for ages, and that it requires yet another dirauth
 script to support. That said, the guardfraction tor code hasn't caused
 bugs to the rest of the codebase and is quite well isolated, so AFAIK the
 biggest issue right now is that some dirauths still run the python script
 and it's burping or filling their disks space.

 I can see some ways forward here:

 a) We go ahead with the plan of comment:6 (and my branch) to kill this
 feature completely, in the assumption that we lack the time and power to
 fix and support it in the medium-term future. If in 3-4 years we decide to
 restart this project we would have to merge the code in again, add more
 consensus methods, etc.
 b) We keep the code in (and maybe obsolete the torrc options) and ask all
 dirauths to stop running the python script until further notice. This
 would be done in the assumption that we would be able to revive this
 project in the future. That said, I think currently the fire department is
 well out of vehicles to even think of reviving this project, let alone
 start doing it.

 Is there a different approach we could take? What should we do?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24456#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online