I suspect this is an undiscovered bug in the fallback directories feature. It hasn't really been an issue until now, as the list of fallback directories has been blank.

I am also concerned that this general area of the code lacks unit tests, which it might be wise to include before we effectively activate it for the first time.

I've created a git branch with a fix in the trac issue #15642 [0].

I've also included unit tests for the function I've modified as a commit in that branch.

But there's currently no coverage for the function that adds fallback directories. (In fact, I mock it in my unit tests, because I need it to do *something* so I know if it has been called or not.)

Loading from an Authority-Signed file of Fallback Directories

The function which loads fallback directories currently loads from a string array inside the function, so it would need to be modified to load from a signed file. I support the security benefits of signed fallback directories enough to write client code and unit tests for it, but I'm not sure how the code for the authorities would work - is the proposal to sign a section of the consensus, and output it as a separate file?

If so, we would either need to backport, and/or wait until a majority of the authorities update to tor versions with the feature. And perhaps a majority of clients as well, 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?