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. 22 May, 2021 1 commit
  6. 11 May, 2021 1 commit
  7. 19 Apr, 2021 2 commits
  8. 17 Apr, 2021 2 commits
  9. 01 Apr, 2021 1 commit
  10. 31 Mar, 2021 1 commit
  11. 29 Mar, 2021 1 commit
  12. 20 Mar, 2021 2 commits
    • intrigeri's avatar
      APT: use non-onion HTTPS sources for Debian repositories · ec836747
      intrigeri authored
      We've observed too much unreliability with Debian's onion APT sources,
      so let's switch to APT sources that should be more reliable.
      Still, to avoid re-introducing fragility wrt. attacks like
      https://www.debian.org/security/2016/dsa-3733 (see refs #8143), we need APT
      sources that support HTTPS, which is not that common.
      My initial intent was to use https://deb.debian.org/, but we lack support for
      SRV records, so that service would HTTP redirect us to one of the CDN instances.
      So I figured skipping this redirection step could be more reliable,
      hence the hard-coding of the Fastly CDN repository sources.
      I'm not too worried about things breaking any time soon due to this hard-coding:
       - The Fastly CDN has backed deb.debian.org since it exists.
       - This configuration is explicitly documented on https://deb.debian.org/.
      So I would expect we would learn about a decommission plan for
      cdn-fastly.deb.debian.org sufficiently in advance to update our config
      in Tails releases before this APT source stops working.
      refs #17993
    • intrigeri's avatar
      Upgrade Tor Browser to 10.0.14-build1. · 28a87107
      intrigeri authored
  13. 17 Mar, 2021 5 commits
  14. 16 Mar, 2021 11 commits
    • boyska's avatar
      onioncircuits: longer options are more readable · 6bdf4e72
      boyska authored
    • boyska's avatar
      tails-create-netns: more consistent style · a6ddff1b
      boyska authored
    • boyska's avatar
      tails-create-netns: avoid bashisms · 3dd6baa4
      boyska authored
    • intrigeri's avatar
    • boyska's avatar
      a11y-proxy-netns: explain behavior with comments · 8881dbfe
      boyska authored
    • boyska's avatar
      review tips: is_veth_nic is more readable · db3fc4be
      boyska authored
    • 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
    • boyska's avatar
      review tips: clearer behaviour · 7106dcda
      boyska authored
    • intrigeri's avatar
      Upgrader hardening: comment out sudo env_keep settings that are not needed in production · 191b04ab
      intrigeri authored
      IIRC kurono verified that these settings did not create security vulnerabilities
      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.
    • 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).
    • intrigeri's avatar
  15. 12 Mar, 2021 1 commit
  16. 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
       - 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
  17. 08 Mar, 2021 4 commits