Bug #8961

The automated test suite doesn't fetch Tor relays from unverified-microdesc-consensus.bak

Added by anonym 2015-02-26 12:35:28 . Updated 2016-06-02 16:52:34 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Test suite
Target version:
Tails_2.4
Start date:
2015-02-26
Due date:
% Done:

100%

Feature Branch:
test/9521-chutney
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
Deliverable for:
270

Description

When checking whether we only contacted the Tor network, we fetch the list of Tor relays known by the test VM via get_all_tor_nodes(). It only look at what’s in /var/lib/tor/cached-microdesc-consensus, but sometimes there may be additional nodes in unverified-microdesc-consensus.bak.

Today I’ve for the first time seen a firewall leak where Tor connected to a node that’s in unverified-microdesc-consensus.bak but not in cached-microdesc-consensus. It seems that the relay was down (all TCP packets were dropped, at least).

Should we also accept connections to nodes only in unverified-microdesc-consensus.bak? I.e.

--- a/features/support/helpers/misc_helpers.rb
+++ b/features/support/helpers/misc_helpers.rb
@@ -93,7 +93,7 @@ end
 # This command will grab all router IP addresses from the Tor
 # consensus in the VM + the hardcoded TOR_AUTHORITIES.
 def get_all_tor_nodes
-  cmd = 'awk "/^r/ { print \$6 }" /var/lib/tor/cached-microdesc-consensus'
+  cmd = 'awk "/^r/ { print \$6 }" /var/lib/tor/*-microdesc-consensus* | sort -u'
   @vm.execute(cmd).stdout.chomp.split("\n") + TOR_AUTHORITIES
 end


After all, that’s what our Tor may do, which may be a bug, possibly due to all the tordate madness we do.

Subtasks

Related issues

Related to Tails - Bug #9654: "IPv4 TCP non-Tor Internet hosts were contacted" during the test suite Resolved 2015-06-29

History

#1 Updated by intrigeri 2015-02-27 10:32:48

Calling this a test suite robustness issue, and hence a subtask of Feature #8539. anonym: IMO next step is to ask Roger or Nick for an “executive summary” of what all these microdesc files are.

#2 Updated by anonym 2015-04-01 13:30:08

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

#3 Updated by intrigeri 2015-05-09 03:39:28

  • Target version changed from Tails_1.4 to Tails_1.4.1
  • Type of work changed from Research to Communicate

Postponing, and adjusting type of work to match what I’ve suggested earlier on this ticket.

#4 Updated by anonym 2015-05-26 20:00:01

  • Status changed from Confirmed to Rejected
  • Assignee deleted (anonym)
  • Target version deleted (Tails_1.4.1)
  • QA Check deleted (Info Needed)

No one else of the usual test suite runners are sure they have seen this. Let’s close this ticket for now.

#5 Updated by anonym 2015-10-17 05:56:14

  • Status changed from Rejected to Confirmed
  • Assignee set to anonym
  • Target version set to Tails_1.8

Ok, I’ve seen this in one run of our isotesters now (originally reported in Feature #10197#note-12).

02:41:14.816   Scenario: The system time is not synced to the hardware clock       # features/time_syncing.feature:86
02:41:19.722     Given I have started Tails from DVD without network and logged in # features/step_definitions/snapshots.rb:174
02:43:27.659     When I bump the system time with "-15 days"                       # features/step_definitions/time_syncing.rb:20
02:43:27.659     And I warm reboot the computer                                    # features/step_definitions/common_steps.rb:458
02:43:27.659     And the computer reboots Tails                                    # features/step_definitions/common_steps.rb:209
02:43:27.659     Then Tails' hardware clock is close to the host system's time     # features/step_definitions/time_syncing.rb:69
02:43:27.659 Full network capture available at: /tmp/TailsToaster/time_syncing_sniffer.pcap-2015-10-16T14:12:46-07:00
02:43:27.659       The following IPv4 TCP non-Tor Internet hosts were contacted:
02:43:27.659       195.88.84.138 (RuntimeError)
02:43:27.659       /var/lib/jenkins/workspace/test_Tails_ISO_feature-10194-tor-0.2.7/features/support/helpers/firewall_helper.rb:120:in `assert_no_leaks'
02:43:27.659       /var/lib/jenkins/workspace/test_Tails_ISO_feature-10194-tor-0.2.7/features/support/hooks.rb:187:in `After'


i.e. due to the @check_tor_leaks flag we detected a leak. Note that we just had updated to tor 0.2.7.3-rc, but I doubt it should matter. I can see that the owner (according to whois) of that IP address, Toile Libre, also runs a relay on 195.88.84.59/@tor.toile-libre.net@. I guess this is an instance of the problem this ticket is about.

#6 Updated by anonym 2015-10-17 05:58:46

Meta: I want to reparent this ticket to Bug #10288 but redmine won’t even allow me to unparent it. Argh!

#7 Updated by intrigeri 2015-10-20 03:41:03

#8 Updated by intrigeri 2015-10-20 03:41:23

  • blocks #8668 added

#9 Updated by intrigeri 2015-10-20 03:42:58

> Meta: I want to reparent this ticket to Bug #10288 but redmine won’t even allow me to unparent it. Argh!

Done via SQL hacks, but this feels wrong: Bug #10288 is about the slice that’s supposed to be completed by October 15, while this ticket has target version = 1.8. See 10288#note-18.

#10 Updated by bertagaz 2015-10-30 11:13:39

This seems to come back a bit since the last 2 or so days, with different IPs (see for example https://jenkins.tails.boum.org/job/test_Tails_ISO_test-10376-fix-startup-page-roadmap-test-is-fragile/16/consoleFull). Wonder if it will last or if it has something to do with Tor 0.2.7. In any case, this probably deserve something.

#11 Updated by intrigeri 2015-11-06 06:07:06

  • Deliverable for set to 270

#12 Updated by anonym 2015-11-06 11:12:01

  • related to Bug #9654: "IPv4 TCP non-Tor Internet hosts were contacted" during the test suite added

#13 Updated by anonym 2015-11-06 11:18:15

  • related to deleted (Bug #9654: "IPv4 TCP non-Tor Internet hosts were contacted" during the test suite)

#14 Updated by anonym 2015-11-06 11:18:48

  • related to Bug #9654: "IPv4 TCP non-Tor Internet hosts were contacted" during the test suite added

#15 Updated by anonym 2015-11-06 12:13:26

  • Target version changed from Tails_1.8 to 246

#16 Updated by sajolida 2015-11-27 04:44:31

  • Target version changed from 246 to Tails_2.0

#17 Updated by anonym 2016-01-06 14:07:40

  • Target version changed from Tails_2.0 to Tails_2.2

#18 Updated by anonym 2016-02-20 13:20:43

  • Priority changed from Normal to Elevated
  • Target version changed from Tails_2.2 to Tails_2.3

I’ll deal with this at the same time as Bug #10238.

#19 Updated by anonym 2016-04-20 10:56:27

  • Target version changed from Tails_2.3 to Tails_2.4

#20 Updated by anonym 2016-06-02 16:52:34

  • Status changed from Confirmed to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100
  • QA Check set to Pass
  • Feature Branch set to test/9521-chutney

anonym wrote:
> I’ll deal with this at the same time as Bug #10238.

Actually, I’m convinced that Chutney (Feature #9521) solved this, so I’m closing this one.