Feature #8960

Test that our test suite's list of Tor authorities is the same as the hardcoded ones in the Tor binary

Added by anonym 2015-02-26 12:24:21 . Updated 2015-03-31 19:02:13 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_1.3.2
Start date:
2015-02-26
Due date:
% Done:

100%

Feature Branch:
test/8960-verify-tor-authorities
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Per Feature #8959, we need to ensure that our list of hardcoded Tor authorities is the same as what’s hardcoded in the shipped Tor binary.

An example of how the string looks in the Tor binary:

Faravahar orport=443 v3ident=EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 154.35.175.225:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC


but there can also be at least the no-v2 and bridge flags (between orport and v3ident). Example regex:

^\S+ orport=\d+ ( bridge)?( no-v2)?v3ident=[A-Z0-9]{40} ${IP_ADDRESS}:\d+( [A-Z0-9]{4}){10}$


So for each ${IP_ADDRESS} in our TOR_AUTHORITIES list, we’d grep for that regex on strings /usr/bin/tor or something. Beautiful!

Subtasks

Related issues

Related to Tails - Feature #8959: Investigate why the automated test suite doesn't fail after Tor authority IP address changes Resolved

History

#1 Updated by intrigeri 2015-03-04 10:00:35

Actually, Feature #8959 can very well be resolved without this one being done.

#2 Updated by intrigeri 2015-03-04 10:00:47

  • related to Feature #8959: Investigate why the automated test suite doesn't fail after Tor authority IP address changes added

#3 Updated by Tails 2015-03-19 13:18:22

  • Status changed from Confirmed to In Progress

Applied in changeset commit:b29dc193db257a57d8588de5a795069c9fd8dca4.

#4 Updated by anonym 2015-03-19 13:18:59

  • Assignee changed from anonym to kytv
  • % Done changed from 0 to 40
  • QA Check set to Ready for QA
  • Feature Branch set to test/8960-verify-tor-authorities

#5 Updated by kytv 2015-03-25 13:42:35

  • Assignee changed from kytv to intrigeri

I guess this is doing what it should.

  Scenario: Tails' Tor binary is configured to use the expected Tor authorities # features/tor_enforcement.feature:13
    Then the Tor binary is configured to use the expected Tor authorities       # features/step_definitions/tor.rb:377
      The Tor binary does not have the expected Tor authorities configured.
      <#<Set: {"86.59.21.38",
       "128.31.0.39",
       "194.109.206.212",
       "82.94.251.203",
       "76.73.17.194",
       "131.188.40.189",
       "193.23.244.244",
       "208.83.223.34",
       "171.25.193.9",
       "154.35.32.5"}>> expected but was
      <#<Set: {"86.59.21.38",
       "128.31.0.39",
       "194.109.206.212",
       "82.94.251.203",
       "131.188.40.189",
       "193.23.244.244",
       "208.83.223.34",
       "171.25.193.9",
       "154.35.175.225",
       "199.254.238.52"}>>.

      diff:
        #<Set: {"86.59.21.38",
         "128.31.0.39",
         "194.109.206.212",
         "82.94.251.203",
      -  "76.73.17.194",
         "131.188.40.189",
         "193.23.244.244",
         "208.83.223.34",
         "171.25.193.9",
      -  "154.35.32.5"}>
      +  "154.35.175.225",
      +  "199.254.238.52"}> (Test::Unit::AssertionFailedError)
      ./features/step_definitions/tor.rb:391:in `/^the Tor binary is configured to use the expected Tor authorities$/'
      features/tor_enforcement.feature:14:in `Then the Tor binary is configured to use the expected Tor authorities'
Scenario failed at time 00:06:36

which also means our hardcoded list is now outdated.

#6 Updated by anonym 2015-03-25 14:29:39

It’s expected. From git diff tor-0.2.5.10..tor-0.2.5.11 -- src/or/config.c:

--- a/src/or/config.c
+++ b/src/or/config.c
@@ -858,9 +858,6 @@ add_default_trusted_dir_authorities(dirinfo_type_t type)
       "194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755",
     "Tonga orport=443 bridge 82.94.251.203:80 "
       "4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D",
-    "turtles orport=9090 "
-      "v3ident=27B6B5996C426270A5C95488AA5BCEB6BCC86956 "
-      "76.73.17.194:9030 F397 038A DC51 3361 35E7 B80B D99C A384 4360 292B",
     "gabelmoo orport=443 "
       "v3ident=ED03BB616EB2F60BEC80151114BB25CEF515B226 "
       "131.188.40.189:80 F204 4413 DAC2 E02E 3D6B CF47 35A1 9BCA 1DE9 7281",
@@ -874,7 +871,10 @@ add_default_trusted_dir_authorities(dirinfo_type_t type)
       "171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810",
     "Faravahar orport=443 "
       "v3ident=EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 "
-      "154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC",
+      "154.35.175.225:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC",
+    "longclaw orport=443 "
+      "v3ident=23D15D965BC35114467363C165C4F724B64B4F66 "
+      "199.254.238.52:80 74A9 1064 6BCE EFBC D2E8 74FC 1DC9 9743 0F96 8145",
     NULL
   };
   for (i=0; authorities[i]; i++) {

I’ve pushed a fix to the branch.

#7 Updated by anonym 2015-03-25 14:31:10

anonym wrote:
> It’s expected.

I should have said, it’s expected if you run a Tails build post-1.3.1, i.e. one which uses Tor 0.2.5.11.

#8 Updated by intrigeri 2015-03-25 14:37:21

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 40 to 100
  • QA Check changed from Ready for QA to Pass

#9 Updated by kytv 2015-03-25 18:36:28

anonym wrote:
> anonym wrote:
> > It’s expected.
>
> I should have said, it’s expected if you run a Tails build post-1.3.1, i.e. one which uses Tor 0.2.5.11.

That’s precisely what I thought (yay for the test finding what it should have found). :)

#10 Updated by anonym 2015-03-31 19:02:13

  • Status changed from Fix committed to Resolved