1. 17 Mar, 2017 1 commit
  2. 30 Jan, 2017 1 commit
  3. 25 Jan, 2017 1 commit
  4. 15 Jan, 2017 1 commit
  5. 23 Dec, 2016 1 commit
  6. 16 Nov, 2016 1 commit
  7. 29 Jul, 2016 1 commit
  8. 22 Jul, 2016 3 commits
  9. 21 Jul, 2016 1 commit
  10. 06 Jun, 2016 1 commit
  11. 04 Jun, 2016 1 commit
  12. 25 May, 2016 1 commit
  13. 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.
  14. 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
    • anonym's avatar
      Improve phrasing. · 2b6626a5
      anonym authored
  15. 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.
  16. 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
      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
  17. 15 Apr, 2016 1 commit
  18. 20 Feb, 2016 1 commit
  19. 08 Jan, 2016 2 commits
  20. 07 Dec, 2015 3 commits
  21. 03 Dec, 2015 1 commit
  22. 15 Oct, 2015 4 commits
  23. 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)
  24. 02 Oct, 2015 1 commit
  25. 14 Aug, 2015 1 commit
  26. 13 Aug, 2015 1 commit
  27. 08 Aug, 2015 2 commits
    • intrigeri's avatar
      Test suite: bump timeout. · ef20dc4e
      intrigeri authored
    • 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.
  28. 05 Aug, 2015 3 commits