[tor-bugs] #19875 [Core Tor/Tor]: shuffle our bridges when we load them from config

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Nov 9 10:03:15 UTC 2016


#19875: shuffle our bridges when we load them from config
--------------------------+------------------------------
 Reporter:  arma          |          Owner:
     Type:  enhancement   |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  easy          |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------

Comment (by teor):

 Replying to [comment:9 arma]:
 > I can see having a ShuffleBridges option during testing the patch, but I
 think the actual patch we merge should be much simpler -- ideally just the
 one line change that I proposed long ago, assuming that works. To be
 clearer, I think any user who is relying on the "one at a time, in that
 order" accidental behavior of bridge lines in torrc is doing it wrong.
 >
 > We would be wise to write a more explanatory comment for the function
 though -- e.g. about how Tor is going to use the order of these bridges in
 its state file, so shuffling will only matter for bridges that aren't
 already in the state file, for example on first run.
 >
 > I'm also a big fan of pastly's notion of tests -- it might take quite a
 bit of testing infrastructure to test this one well.

 Typically, we implement tests with random outcomes by working out what the
 probability of a random bit flip is, and then run the test enough times
 that the failure rate is less than the bit flip rate.

 (Hmm, we should standardise this, see #20617.)

 For current examples of code that tests random outcomes, see
 test_crypto_rng_range and crypto_rand_check_failure_mode_zero.

 As a concrete example, let's say you have a unit test with two bridges, A
 and B.
 Let's also say that the current code always chooses A.
 The new code is expected to choose A or B, uniformly at random.
 To keep the failure rate below `2^2048` (which is what
 crypto_rand_check_failure_mode_zero uses), run the test 2048 times. If it
 comes up A each time, it is almost certain that the code is broken.

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


More information about the tor-bugs mailing list