Feature #9377

Test that a hardware clock way in the past results in a system clock set to the build date

Added by anonym 2015-05-12 09:54:55 . Updated 2015-07-03 03:39:13 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_1.4.1
Start date:
2015-05-12
Due date:
% Done:

50%

Feature Branch:
test/9377-clock-sanity-check
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

The fix for Bug #9149 makes us do that, which makes the two “Clock way in the past” scenario impossible. So we should remove them and instead test that this sanity check works.

Subtasks

History

#1 Updated by anonym 2015-05-12 10:01:19

  • Status changed from Confirmed to In Progress

Applied in changeset commit:f9658a9f60e444a8ec9fbb0cbb6b36375ebb6311.

#2 Updated by anonym 2015-05-12 10:06:50

  • Assignee changed from anonym to kytv
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to test/9377-clock-sanity-check

I ran the new scenario successfully for Tails 1.4, but it fails, as expected, for Tails 1.3.2 (i.e. prior to the fix for Bug #9149) with:

  Scenario: Skip the background snapshot, boot with a hardware clock set way in the past and make sure that Tails sets the clock to the build date # features/time_syncing.feature:8
    Given a computer                                                                                                                               # features/step_definitions/common_steps.rb:66
    And the network is unplugged                                                                                                                   # features/step_definitions/common_steps.rb:119
    And the hardware clock is set to "01 Jan 2000 12:34:56"                                                                                        # features/step_definitions/common_steps.rb:124
    And I start the computer                                                                                                                       # features/step_definitions/common_steps.rb:146
    And the computer boots Tails                                                                                                                   # features/step_definitions/common_steps.rb:224
    Then the system clock is just past Tails' build date                                                                                           # features/step_definitions/time_syncing.rb:46
      The system time (2000-01-01 13:35:42 +0100) is before the Tails build date (2015-03-30 02:00:00 +0200).
      <false> is not true. (Test::Unit::AssertionFailedError)

#3 Updated by anonym 2015-05-12 10:25:42

I just realized that my branch doesn’t check that the hardware clock is actually set (similar to how we verify that date --set works in the other tests). However, we’d only get a false positive if libvirt fails to set the hardware clock and:

1. the image is built very early some day (i.e. close to 00:00:00)
2. the test suite runs the new scenario before 00:30:00 o’clock

=> Tails has a system time within the allowed span, but it wasn’t because it was set to it by our sanity checker, but because the host’s time was synced to the Tails guest.

I’m not sure I care about this, especially since it’s quite hard to test that the clock was set correctly since it has to be done before we have the remote shell. I guess we could boot with “nosplash break=bottom” on the kernel command-line, run date in the initramfs shell and… then what? We can’t match against a static image since the expected date output will change depending on when the ISO was built, and Sikuli’s OCR capabilities are downright rotten.

#4 Updated by anonym 2015-05-12 10:27:06

anonym wrote:
> We can’t match against a static image since the expected date output will change depending on when the ISO was built, and Sikuli’s OCR capabilities are downright rotten.

But we could write the date output to a file that we check once the remote shell is up. Hmm. Do we care?

#5 Updated by kytv 2015-05-14 18:24:49

  • Assignee changed from kytv to intrigeri

anonym wrote:
> anonym wrote:
> > We can’t match against a static image since the expected date output will change depending on when the ISO was built, and Sikuli’s OCR capabilities are downright rotten.
>
> But we could write the date output to a file that we check once the remote shell is up. Hmm. Do we care?

I don’t think so, but the second reviewer may have a different opinion.

Code review and testing passed.

#6 Updated by intrigeri 2015-05-15 17:39:25

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:e8da49eb6f677636479652671b861cef36923bac.

#7 Updated by intrigeri 2015-05-15 17:40:28

  • Assignee deleted (intrigeri)
  • % Done changed from 100 to 50
  • QA Check changed from Ready for QA to Pass

Agreed, and merged!

#8 Updated by intrigeri 2015-07-03 03:39:13

  • Status changed from Fix committed to Resolved