1. 07 Jun, 2021 2 commits
  2. 30 May, 2021 2 commits
  3. 25 May, 2021 2 commits
  4. 23 May, 2021 1 commit
  5. 11 May, 2021 1 commit
  6. 19 Apr, 2021 2 commits
  7. 17 Apr, 2021 2 commits
  8. 01 Apr, 2021 1 commit
  9. 31 Mar, 2021 1 commit
  10. 29 Mar, 2021 1 commit
  11. 20 Mar, 2021 1 commit
  12. 17 Mar, 2021 5 commits
  13. 16 Mar, 2021 10 commits
    • boyska's avatar
      onioncircuits: longer options are more readable · 6bdf4e72
      boyska authored
      6bdf4e72
    • boyska's avatar
      tails-create-netns: more consistent style · a6ddff1b
      boyska authored
      a6ddff1b
    • boyska's avatar
      tails-create-netns: avoid bashisms · 3dd6baa4
      boyska authored
      3dd6baa4
    • intrigeri's avatar
      955416c4
    • boyska's avatar
      a11y-proxy-netns: explain behavior with comments · 8881dbfe
      boyska authored
      8881dbfe
    • boyska's avatar
      review tips: is_veth_nic is more readable · db3fc4be
      boyska authored
      db3fc4be
    • intrigeri's avatar
      Retry failed upgrade downloads, reusing the previously downloaded data, and... · 8b67924c
      intrigeri authored
      Retry failed upgrade downloads, reusing the previously downloaded data, and fallback to the DNS mirror pool
      
      This is the solution called "C + fallback DNS pool" on #15875.
      
      Incidentally, since the SocksPort we're using has IsolateDestAddr and
      IsolateDestPort, this also gives us "C + new Tor circuit" for the last retry in
      most cases (that is, unless the mirror picked from mirrors.json, that we tried
      to download from previously, is in the DNS pool, and we pick it again from from
      the DNS pool).
      
      This should allow the Upgrader to recover, transparently for the user, from
      a number of failure modes, such as:
      
       - We picked a mirror that's down or flaky.
       - We picked an out-of-sync mirror that lacks the data we need to download.
       - The user's Internet connection is flaky.
       - We picked a flaky Tor circuit.
      
      Regarding the added test scenarios:
      
       - For the "Successfully resuming an interrupted download, from the same mirror"
         scenario, I failed to find a simple enough way to set up a webserver that would
         fail once and then start working again, so I implemented the webserver mocking
         code directly in Tails::IUK::TargetFile::Download, which is not ideal.
      
       - For the "Successfully resuming an interrupted download, using the fallback
         mirror pool" scenario, I could have run a broken webserver and a functioning
         fallback one. But once I had the mocking code mentioned above, it was vastly
         simpler to just use it here as well.
      
      refs #15875
      8b67924c
    • boyska's avatar
      review tips: clearer behaviour · 7106dcda
      boyska authored
      7106dcda
    • intrigeri's avatar
      Tails::Download::HTTPS hardening: drop support for SSL_NO_VERIFY · d989f5f8
      intrigeri authored
      This option leaves the door open to some persistent local privilege
      exploitation. IIRC kurono verified that it was not a problem in practice,
      but I find it safer not to take any chances, and I prefer not having
      to constantly reason about whether that remains safe enough.
      
      This option was only used by one step of our manual test suite, which:
      
       - required a complex local setup that most manual testers don't have
         (even I haven't had it ready anymore since years)
      
       - is now useless not only because our release process publishes the UDFs on the
         test channel, but also because when a manual tester reaches this point, IUKs
         are supposed to be available on most mirrors already (and even the RM took
         a risky shortcut, with #15287, the delay caused by uploading the IUKs goes
         away, so the chances the IUKs are available is higher).
      d989f5f8
    • intrigeri's avatar
      f3b56073
  14. 09 Mar, 2021 1 commit
    • intrigeri's avatar
      On boot, repair the filesystem on the system partition · 9fa4bc54
      intrigeri authored
      This will fix filesystems affected by #17902 (phantom space occupied on the
      system partition by previously deleted obsolete automatic upgrades), for users
      who:
      
       - Either, still have enough usable free space to automatically upgrade to
         a release that includes this fix.
      
       - Or, will manually upgrade to a release that includes this fix.
      
      And more generally, it's good practice to fsck filesystems at boot time:
      this will automatically recover from other failure modes.
      
      refs #17902
      9fa4bc54
  15. 08 Mar, 2021 8 commits