Tails

#1 Updated by intrigeri 2016-03-26 10:33:16

• related to Feature #5774: Robust time syncing added

#2 Updated by intrigeri 2016-03-26 10:35:29

• Assignee set to anonym
• QA Check set to Ready for QA

anonym: given what I wrote in the description, I think we don’t need to disable that new feature, but we’ll need to update the design doc accordingly. What do you think?

#3 Updated by anonym 2016-04-13 07:06:44

• Assignee changed from anonym to intrigeri
• QA Check changed from Ready for QA to Info Needed

intrigeri wrote:
> anonym: given what I wrote in the description, I think we don’t need to disable that new feature, but we’ll need to update the design doc accordingly. What do you think?

I agree.

However, I wonder if we have to rethink how we decide which nodes are ok to contact, e.g. the TOR_AUTHORITIES constant defined in features/support/config.rb. If any of these fallback directories do not appear in the consensus, we’ll not consider them as ok to contact => test failure for all @check_tor_leaks-tagged scenarios. Apparently they will be hardcoded in Tor’s source, but hopefully we can query this via the control port, otherwise I suppose we’ll have to grep them from the system under testing’s Tor binary (yay!) or something similarly hideous. Or am I missing something?

#4 Updated by intrigeri 2016-04-15 04:39:39

• Status changed from Confirmed to In Progress
• Parent task set to Feature #11351

#5 Updated by intrigeri 2016-04-15 04:51:07

• Assignee changed from intrigeri to anonym

>> anonym: given what I wrote in the description, I think we don’t need to disable that new feature, but we’ll need to update the design doc accordingly. What do you think?

> I agree.

OK, filed Feature #11352 about it.

> However, I wonder if we have to rethink how we decide which nodes are ok to contact, e.g. the TOR_AUTHORITIES constant defined in features/support/config.rb. If any of these fallback directories do not appear in the consensus, we’ll not consider them as ok to contact => test failure for all @check_tor_leaks-tagged scenarios. Apparently they will be hardcoded in Tor’s source, but hopefully we can query this via the control port, otherwise I suppose we’ll have to grep them from the system under testing’s Tor binary (yay!) or something similarly hideous. Or am I missing something?

My understanding is that indeed, this is a realistic failure mode for our test suite. I seems that this problem will rarely happen, since fallback directory mirrors are picked from the set of relays, so in general they should be in the consensus. But still, let’s avoid adding one more cause for test suite fragility.

I doubt the control port will give us access to that info, so it might be that we need to include src/or/fallback_dirs.inc in the SquashFS, and to read+parse it while running the test suite.

If you think that’s doable, please file a subtask of Feature #11351 that would be dedicated to updating these test suite aspects, and then close this very ticket.

If you think it’s not OK, then let’s discuss it further here.

#6 Updated by anonym 2016-04-25 03:56:03

• Assignee changed from anonym to intrigeri

OTOH, since the plan seems to be to run our own Tor network via Chutney in our test suite (Feature #9521) we won’t run any fallback directories unless we explicitly want to, and will therefore be able to just ignore this. Right? (At least if we go the path where we have no tests for using the real Tor network, which I am getting more and more convinced is the right idea for similar reasons to this issue.)

#7 Updated by intrigeri 2016-04-25 04:27:13

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

#8 Updated by intrigeri 2016-04-29 02:54:18

• Assignee changed from intrigeri to anonym

> OTOH, since the plan seems to be to run our own Tor network via Chutney in our test suite (Feature #9521) we won’t run any fallback directories unless we explicitly want to, and will therefore be able to just ignore this. Right? (At least if we go the path where we have no tests for using the real Tor network, which I am getting more and more convinced is the right idea for similar reasons to this issue.)

This sounds correct :)

Then I think we can close this ticket.

But then Feature #11351 needs to be blocked by Feature #9521, to make sure we don’t “temporarily” introduce more robustness issues, no? Or, given Tor tests are disabled on Jenkins anyway, we don’t bother too much, and we’ll deal with such rare false positives ourselves when running the test suite locally. Your call.

#9 Updated by anonym 2016-05-08 03:39:27

• Status changed from In Progress to Resolved
• Assignee deleted (anonym)
• % Done changed from 0 to 100
• QA Check changed from Info Needed to Pass