Feature #8959

Investigate why the automated test suite doesn't fail after Tor authority IP address changes

Added by anonym 2015-02-26 12:02:42 . Updated 2015-03-22 11:59:09 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_1.3.1
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

The automated test suite hard codes the list of Tor authority IP addresses, and uses them in the firewall checker mechanism. Hence if a Tor authority changes IP address, we should expect failures if we do not update the list too. However, it seems we don’t get any errors. For instance, on 2015-02-20 Faravahar changed IP address but I have yet to see a failure.

Subtasks

Related issues

Related to Tails - Feature #8960: Test that our test suite's list of Tor authorities is the same as the hardcoded ones in the Tor binary Resolved 2015-02-26

History

#1 Updated by anonym 2015-02-26 12:09:20

Actually, what we need to ensure is that our hardcoded list in the test suite is the same as the one in the Tor binary we ship for a given Tails version. If some dir auth gets a new IP address, it’s expected that current stable Tor releases will have and use the out-dated IP address, since it’s hardcoded in it. So it will continue to try the old addresses, and probably fail (unless there’s some temporary redirection set up). If we would update our hardcoded list of dir auths before we ship a Tor binary with an updated list of dir auths, we’d get firewall leak errors when Tor (correctly) contacts the old dir auth address.

Conclusion: we just need to ensure that our test suite’s list matches the one in the shipeed Tor binary, even if a dir auth IP address change has occurred in the real world. In fact, we should test that these lists are the same.

#2 Updated by anonym 2015-02-26 12:25:26

Next step: run the test suite with an empty TOR_AUTHORITIES.

#3 Updated by anonym 2015-02-26 13:37:54

  • Assignee deleted (anonym)
  • QA Check set to Info Needed

Ok, I’ve run several Tor heavy .feature:s with an empty TOR_AUTHORITIES list, and something definitely seemed off — I would expect to get an error for each scenario tagged @check_tor_leaks, since we’d have to bootstrap against some authority, and we allow none. However, I only got the expected error once out of eight Tor bootstraps.

Luckily, the explanation is benign: Some directory authorities also run Tor relays, and so end up in the cached-microdesc-consensus that we fetch the Tor relays from. The only authorities that doesn’t are:

  • 76.73.17.194
  • 212.112.245.170

and it was when my Tor happened to bootstrap against one of these I got the error. Hence our test suite seems to be correct in this regard.

Can someone please double-check my reasoning here?

#4 Updated by intrigeri 2015-02-27 10:35:46

  • Assignee set to kytv
  • QA Check changed from Info Needed to Ready for QA

anonym wrote:
> Can someone please double-check my reasoning here?

Let’s call this needing QA, and hence putting on kytv’s plate, then :)

#5 Updated by kytv 2015-02-28 02:52:15

This seems to be correct but I want to give this a bit more thought.

#6 Updated by kytv 2015-03-03 22:36:11

  • Assignee changed from kytv to intrigeri

After dwelling on this for a few days, yes, I think the diagnosis expressed above at Feature #8959#note-3 is correct.

(Passing to intrigeri for a third opinion. Please let me know if setting QA Check: Pass is what I should have done.)

#7 Updated by intrigeri 2015-03-04 10:00:48

  • related to Feature #8960: Test that our test suite's list of Tor authorities is the same as the hardcoded ones in the Tor binary added

#8 Updated by intrigeri 2015-03-04 10:01:41

  • Status changed from Confirmed to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

I’m convinced.

#9 Updated by BitingBird 2015-03-22 11:59:09

  • Target version changed from Tails_1.3.2 to Tails_1.3.1