Project

General

Profile

Feature #9377

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

Added by anonym over 4 years ago. Updated about 4 years ago.

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

50%

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

Description

The fix for #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.

Associated revisions

Revision f9658a9f (diff)
Added by anonym over 4 years ago

Test the system clock sanity check we do at boot.

I.e. check that

config/chroot_local-includes/lib/live/config/0001-sane-clock

does what it's supposed to, which is to ensure that the system clock
cannot be set before the Tails build date (if so, we set it to the
Tails build date).

Will-fix: #9377

Revision e8da49eb
Added by intrigeri over 4 years ago

Merge remote-tracking branch 'origin/test/9377-clock-sanity-check' into stable

Fix-committed: #9377

History

#1 Updated by anonym over 4 years ago

  • Status changed from Confirmed to In Progress

#2 Updated by anonym over 4 years ago

  • 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 #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 over 4 years ago

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 over 4 years ago

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 over 4 years ago

  • 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 over 4 years ago

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

#7 Updated by intrigeri over 4 years ago

  • 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 about 4 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF