1. 14 Sep, 2017 1 commit
  2. 07 Jun, 2017 1 commit
  3. 20 Mar, 2017 1 commit
    • anonym's avatar
      Test suite: fixes to make 3.0~beta3 pass. · b715ce42
      anonym authored
      This includes:
      
      * fixing some mistakes in the merge conflict resolution
        28cf4852.
      
      * switching to an image in the Pidgin tests that doesn't depend on the
        /topic of tails@conference.riseup.net -- the server resets it every
        once in a while, so we should not pretend the test suite can always
        find it.
      
      * Fix a problematic use of try_for (we need refs: #9223!).
      
      * Fix for VM.select_virtual_desktop() and VM.do_focus(): in Stretch we
        only have two virtual desktop, so do_focus() has been broken for a
        while. Also add some `sleep()`:s which sadly seem required.
      
      * Random Gherkin improvement.
      b715ce42
  4. 17 Mar, 2017 1 commit
  5. 30 Jan, 2017 1 commit
  6. 25 Jan, 2017 1 commit
  7. 15 Jan, 2017 1 commit
  8. 23 Dec, 2016 1 commit
  9. 16 Nov, 2016 1 commit
  10. 29 Jul, 2016 1 commit
  11. 22 Jul, 2016 3 commits
  12. 21 Jul, 2016 1 commit
  13. 06 Jun, 2016 1 commit
  14. 04 Jun, 2016 1 commit
  15. 25 May, 2016 1 commit
  16. 21 May, 2016 1 commit
    • anonym's avatar
      Dogtailify step. · d014c7c6
      anonym authored
      This step was broken due to Tor Browser 6.0.x changing the zoom-levels
      (or similar) so various elements of the just removed image were not
      positioned the way we expected them.
      d014c7c6
  17. 11 May, 2016 2 commits
    • anonym's avatar
      Drop the usage of Tor Check in our tests. · e500661b
      anonym authored
      It doesn't make sense now when we use Chutney since that always means
      it will report that Tor is not being used.
      
      In some scenarios we used it simply because we needed *some* page
      (distinct from the Tails News page) and we had the image. In those
      cases we now use the Tails homepage instead. I tried to use dogtail,
      but realized that dogtail won't work for the Unsafe Browser due to
      e500661b
    • anonym's avatar
      Improve phrasing. · 2b6626a5
      anonym authored
      2b6626a5
  18. 04 May, 2016 1 commit
    • anonym's avatar
      Always run the 'the Tails desktop is ready' step. · fc777723
      anonym authored
      ... after logging in via Tails Greeter. Now we do some very important
      stuff there, like enabling the accessibility toolkit in GNOME. That is
      specifically something we lose if we forgot to run that step after
      rebooting, which specifically was a problem in at least one scenario
      (Deleting a Tails persistent partition).
      
      While we're at it, let's also run the 'Tails Greeter has dealt with
      the sudo password' step at the same time.
      fc777723
  19. 20 Apr, 2016 1 commit
    • anonym's avatar
      Completely rewrite the firewall leak detector. · c2a2465c
      anonym authored
      The old design was very inflexible, which over time lead to the
      implementation growing messy as different checks were added. The
      issue was that it had to hard-code the particular checks we
      wanted, and did not allow the user to formulate an expression for
      which packets are considered leaks or not. So, let's instead
      provide an assertion-like function to which the user passes a
      block describing how we want all our packets to look.
      
      Furthermore, now all firewall leak tests should be ok with the
      simulated Tor network provided by Chutney. Since all Tor nodes
      (incl. bridges) run from the same host (and IP address) we also
      include the server port when verifying that no unexpected hosts were
      contacted.
      
      Note that in some cases we've lost a bit of information and
      precision, e.g. among the anti-tests we no longer exactly match
      the protocol that was leaked, but that wasn't very valuable to
      begin with, and instead we test *exactly* the code that these are
      anti tests for -- a true anti test, indeed!
      
      Also, the 'no traffic has flowed to the LAN' (now renamed) had a
      serious bug which was fixed in passing -- the `@lan_host`
      variable was not set, so it is `nil`, which could never be among
      the IPv4 TCP leaks, so that step always succeeded! :S
      c2a2465c
  20. 15 Apr, 2016 1 commit
  21. 20 Feb, 2016 1 commit
  22. 08 Jan, 2016 2 commits
  23. 07 Dec, 2015 3 commits
  24. 03 Dec, 2015 1 commit
  25. 15 Oct, 2015 4 commits
  26. 06 Oct, 2015 1 commit
    • anonym's avatar
      Improve names of generated snapshot restoring steps. · 83bde0f9
      anonym authored
      Essentially I did:
      
          sed -i 's/Tails has booted/I have started Tails/' -- \
              features/*.feature features/step_definitions/snapshots.rb
      
      (although there was a false positive that I had to restore)
      83bde0f9
  27. 02 Oct, 2015 1 commit
  28. 14 Aug, 2015 1 commit
  29. 13 Aug, 2015 1 commit
  30. 08 Aug, 2015 2 commits
    • intrigeri's avatar
      Test suite: bump timeout. · ef20dc4e
      intrigeri authored
      ef20dc4e
    • anonym's avatar
      Rework how we test AppArmor denials. · 5cb5daf4
      anonym authored
      The basic idea is to first run a "I start monitoring the AppArmor log"
      step, which records the current time, and that any "AppArmor has
      denied" step run for the same profile later will only look at entries
      from that time and on. The wordings on the steps now make the
      scenarios a bit clearer, and we also don't have to clear syslog any
      more as an ugly workaround.
      
      Furthermore, this will bring us close to a clean solution of #9924,
      which will require us to run a sysctl command *before* anything that
      could generate the AppArmor log entries we're interested in. The "I
      monitor" step is a perfect candidate for that, wereas we before would
      need yet another step.
      5cb5daf4