1. 19 Jul, 2020 1 commit
    • intrigeri's avatar
      Test suite: make "Scenario: The Additional Software dpkg hook notices when... · dd0274a7
      intrigeri authored
      Test suite: make "Scenario: The Additional Software dpkg hook notices when persistence is locked down while installing a package" more robust
      
      I've seen a case when this step:
      
          Then the Additional Software dpkg hook has been run for package "makepp" and notices the persistence is locked
      
      … failed with a timeout waiting for the expected message to appear in the
      logs, while the /run/live-additional-software/log artifact saved by the test
      suite a few seconds after this timeout expired does include that message.
      
      So, let's:
      
       - wait a bit longer
       - increase the delay between try_for iterations, to avoid the test suite itself
         slowing down the very thing we're waiting for (i.e. the Additional Software
         dpkg hook).
      dd0274a7
  2. 24 Jun, 2020 1 commit
  3. 10 May, 2020 1 commit
  4. 24 Apr, 2020 1 commit
  5. 23 Apr, 2020 2 commits
  6. 22 Apr, 2020 1 commit
  7. 21 Apr, 2020 9 commits
  8. 01 Sep, 2019 1 commit
    • intrigeri's avatar
      Test suite: make the "Additional Software is correctly configured for package" step more robust. · f80cf475
      intrigeri authored
      I've seen it fail with:
      
            And I accept adding "cowsay" to Additional Software                                                                               # features/step_definitions/additional_software_packages.rb:68
        02:10:40.714306961: Remote shell: calling as root: test -e '/live/persistence/TailsData_unlocked/live-additional-software.conf'
        02:10:41.534017376: call returned: [0, "", ""]
        02:10:41.534315412: Remote shell: calling as root: ls -1 -d /live/persistence/*_unlocked/
        02:10:41.870330265: call returned: [0, "/live/persistence/TailsData_unlocked/\n", ""]
        02:10:41.870622831: Remote shell: calling as root: test -e /live/persistence/TailsData_unlocked//persistence.conf
        02:10:42.061890291: call returned: [0, "", ""]
        02:10:42.062127576: Remote shell: calling as root: tails-version
        02:10:42.559974366: call returned: [0, "4.0~beta2 - 20190812\nf13ea3fd\nlive-build: 3.0.5+really+is+2.0.12-0.tails5\nlive-boot: 1:20170112\nlive-config: 5.20190519\n", ""]
        02:10:42.560209029: Remote shell: calling as root: test -e /live/persistence/TailsData_unlocked//persistence.conf.bak
        02:10:42.836461995: call returned: [0, "", ""]
        02:10:42.836740590: Remote shell: calling as root: test ! -e /live/persistence/TailsData_unlocked//live-persistence.conf
        02:10:43.115766459: call returned: [0, "", ""]
        02:10:43.115995641: Remote shell: calling as root: ls -1 /live/persistence/TailsData_unlocked//persistence.conf* /live/persistence/TailsData_unlocked//live-*.conf
        02:10:43.417454108: call returned: [0, "/live/persistence/TailsData_unlocked//live-additional-software.conf\n/live/persistence/TailsData_unlocked//persistence.conf\n/live/persistence/TailsData_unlocked//persistence.conf.bak\n", ""]
        02:10:43.417665018: Remote shell: calling as root: stat -c %U '/live/persistence/TailsData_unlocked//live-additional-software.conf'
        02:10:43.626864841: call returned: [0, "tails-persistence-setup\n", ""]
        02:10:43.627060549: Remote shell: calling as root: stat -c %G '/live/persistence/TailsData_unlocked//live-additional-software.conf'
        02:10:43.864667214: call returned: [0, "tails-persistence-setup\n", ""]
        02:10:43.864916743: Remote shell: calling as root: stat -c %a '/live/persistence/TailsData_unlocked//live-additional-software.conf'
        02:10:44.143865252: call returned: [0, "644\n", ""]
        02:10:44.144191068: Remote shell: calling as root: stat -c %U '/live/persistence/TailsData_unlocked//persistence.conf'
        02:10:44.571728279: call returned: [0, "tails-persistence-setup\n", ""]
        02:10:44.572001142: Remote shell: calling as root: stat -c %G '/live/persistence/TailsData_unlocked//persistence.conf'
        02:10:44.849157870: call returned: [0, "tails-persistence-setup\n", ""]
        02:10:44.849391246: Remote shell: calling as root: stat -c %a '/live/persistence/TailsData_unlocked//persistence.conf'
        02:10:45.330177056: call returned: [0, "644\n", ""]
            And Additional Software is correctly configured for package "cowsay"                                                              # features/step_definitions/additional_software_packages.rb:50
              <"600"> expected but was
              <"644">. (Test::Unit::AssertionFailedError)
              ./features/step_definitions/usb.rb:558:in `block (3 levels) in <top (required)>'
              ./features/step_definitions/usb.rb:548:in `each'
              ./features/step_definitions/usb.rb:548:in `block (2 levels) in <top (required)>'
              ./features/step_definitions/usb.rb:537:in `/^all persistence configuration files have safe access rights$/'
              features/additional_software_packages.feature:75:in `And Additional Software is correctly configured for package "cowsay"'
      
      That's not surprising because:
      
      1. The previous step is:
      
            I accept adding "cowsay" to Additional Software
      
         … and all it does is clicking on the "Install Every Time" button,
         which triggers tails-persistence-setup, but does not wait for it
         to finish its job.
      
      2. The "save" method in Tails::Persistence::Configuration::ConfigFile does this:
      
            $self->config_file_path->spew($self->output);
            $self->config_file_path->chmod(0600);
      
         … so there's a short window, while (re)configuring a persistent volume,
         during which which persistence.conf has permissions 0644 instead of 0600.
      
         The documentation for the "spew" method in Path::Tiny explains that
         this surprising behaviour is actually a security feature:
      
           NOTE: because the file is written to a temporary file and then renamed,
           the new file will wind up with permissions based on your current umask.
           This is a feature to protect you from a race condition that would
           otherwise give different permissions than you might expect. If you
           really want to keep the original mode flags, use "append" with the
           "truncate" option.
      
      So, this step is racing against the very thing it's validating.
      Let's retry the checks to give tails-persistence-setup some more time
      to do its job, before we verify it has done so properly.
      f80cf475
  9. 11 Jul, 2019 2 commits
  10. 18 Jun, 2019 1 commit
    • intrigeri's avatar
      Test suite: don't rely on mtimes from Debian packages we download, to indicate... · 580e9d83
      intrigeri authored
      Test suite: don't rely on mtimes from Debian packages we download, to indicate which one has the biggest version (refs: #16819).
      
      These mtimes are copied from the HTTP server where APT downloads packages from.
      
      In "Scenario: Recovering in offline mode after Additional Software previously
      failed to upgrade and then succeed to upgrade when online", after we've done "I
      prepare the Additional Software upgrade process to fail", the APT cache on
      Buster has:
      
      -rw-r--r-- 1 root root 20296 Apr  1  2018 cowsay_3.03+dfsg2-1_all.deb
      -rw-r--r-- 1 root root 20856 Feb  5 01:06 cowsay_3.03+dfsg2-6_all.deb
      
      … and we want the dpkg hook installed by this step to delete the one with the
      largest version number, i.e. cowsay_3.03+dfsg2-6.
      
      But the previous code, based on "ls -tr1 | head -n 1" would delete the file with
      the oldest mtime (cowsay_3.03+dfsg2-1) when run on Buster, instead of
      cowsay_3.03+dfsg2-6, so the upgrade we wanted to make fail succeeds,
      and in turn this step fails:
      
        I see the "The upgrade of your additional software failed" notification after at most 300 seconds
      
      FWIW, I think the previous code happened to work on Stretch merely because the
      mtime of cowsay_3.03+dfsg2-1_all.deb in our custom APT repo was newer than the
      one of Stretch's 3.03+dfsg2-3, since we had uploaded it at a later time.
      But if a 3.03+dfsg2-3+deb9u1 was ever released, if my hypothesis is correct,
      this test would start failing on Stretch in the exact same way.
      
      Let's not rely on such mtimes and instead, use ls' ability to sort
      by version number, to pick the biggest one.
      580e9d83
  11. 23 May, 2019 1 commit
  12. 09 Apr, 2019 1 commit
    • anonym's avatar
      Test suite: be more careful when finding ASP notifications. · d58c7f34
      anonym authored
      For some reason both the label and button has a "weird"
      invisible (despite `showingOnly`) twins located just below the
      Applications menu. So let's make some extra effort to actually find
      the real notification, and then look for the label and button among
      its children.
      d58c7f34
  13. 06 Mar, 2019 1 commit
  14. 05 Mar, 2019 5 commits
  15. 04 Mar, 2019 1 commit
  16. 27 Jan, 2019 1 commit
    • intrigeri's avatar
      Test suite: don't look for an unrelated notification when checking if... · 354db2e5
      intrigeri authored
      Test suite: don't look for an unrelated notification when checking if tails-additional-software-upgrade.service has started (refs: #14596)
      
      This service does not display notifications on success: only
      tails-additional-software-install.service does.
      
      Context: I'm trying to wrap my mind around how Additional Software notifications
      are handled in the test suite and it confused me a bit that we were looking for
      a notification that is unrelated to what this step is testing.
      354db2e5
  17. 25 Jan, 2019 5 commits
  18. 26 Nov, 2018 1 commit
  19. 25 Nov, 2018 1 commit
  20. 24 Nov, 2018 1 commit
  21. 23 Nov, 2018 2 commits