1. 11 Feb, 2016 1 commit
    • anonym's avatar
      Add set -u to all gettext:ized shell scripts. · 74a91c28
      anonym authored
      In gettext-base < 1.8.2, like the one we had in Wheezy, gettext.sh
      references the environment variable ZSH_VERSION, which we do not
      set. This has prevented us from doing `set -u` in all gettext:ized
      shell scripts unless we first initialize that variable before sourcing
      gettext.sh.
      
      Now that we install a new enough gettext-base, we can finally do this
      and remove the initialization hacks.
      
      Will-fix: #9371
      74a91c28
  2. 10 Feb, 2016 3 commits
    • anonym's avatar
      Do the fontconfig dance with all browsers. · a8021ec0
      anonym authored
      I.e. also the Unsafe and I2P Browser's. The main reason is so we do
      not need different images for these and the Tor browser in the
      automated test suite. One may argue, though, that for the Unsafe
      Browser this list of fonts would be fingerprintable, but I would be
      surprised if it already isn't so due to the Tor Browser Firefox
      patches.
      a8021ec0
    • anonym's avatar
      Use an appropriate working directory when launching the Tor Browser. · 4173d78b
      anonym authored
      The Tor Browser assumes that the working directory is the directory
      where the browser lives (e.g. the executable). For instance, the
      fonts.conf (for fontconfig) the Tor Browser uses looks for the fonts
      in the "fonts" sub-directory of the current working directory. This
      will fix issues with "empty boxes" as characters in the Save As/Open
      dialoges.
      
      Will-fix: #11097
      4173d78b
    • anonym's avatar
      Propagate Tor Launcher options via the wrapper. · 2fc6d139
      anonym authored
      E.g. for our custom/undocumented (but so far unused)
      `--force-net-config` option.
      2fc6d139
  3. 09 Feb, 2016 8 commits
  4. 08 Feb, 2016 1 commit
  5. 04 Feb, 2016 4 commits
  6. 26 Jan, 2016 1 commit
  7. 25 Jan, 2016 1 commit
  8. 22 Jan, 2016 1 commit
  9. 11 Jan, 2016 1 commit
  10. 10 Jan, 2016 3 commits
  11. 09 Jan, 2016 3 commits
  12. 05 Jan, 2016 2 commits
  13. 03 Jan, 2016 1 commit
  14. 02 Jan, 2016 1 commit
  15. 18 Dec, 2015 1 commit
  16. 14 Dec, 2015 3 commits
  17. 10 Dec, 2015 1 commit
  18. 09 Dec, 2015 4 commits
    • Tails developers's avatar
      Rename sdmem script. · f3f44843
      Tails developers authored
      The script runs `killall sdmem`, which kills itself.
      f3f44843
    • Tails developers's avatar
      Make parallel sdmem faster and more robust. · a3c19d42
      Tails developers authored
      Initial description:
      
        We avoid running too many parallel instances (which adds overhead) by
        only running one instance per 2048 MiB of RAM (which is below the x86
        per-process limitation). This also seems to play better with
        VirtualBox, which often hangs when running too many sdmem in parallel.
      
        Furthermore we kill all sdmem instances as soon as one of them has
        been oom killed; after all, that implies that the memory has been
        completely filled, so we're done. If we don't kill the others they may
        continue running unecessarily, filling the freed memory of the killed
        instance, and so on.
      
        Another consequence of this is cleaner output so that the debug
        message (that memory dumping can ensue) will be easier to spot when
        running with boot option debug=wipemem. That will be a helpful cue
        for the automated test suite.
      
      Three years later, when revisiting this idea, we realized that the
      reasoning above is not 100%-correct on 32-bit: in theory there could
      always be one process that runs ahead of all the others, and reaches the
      per-process limit is killed. Then another one does, and so on, and in
      the end all sdmem processes have been killed due to the per-process
      limit, not because the memory was filled. However:
      
      * In practice, this will-fix: #9707, while still erasing almost all
        memory according to our test suite.
      
      * 32-bit systems that have more than 2GB of RAM are pretty rare anyway.
      a3c19d42
    • intrigeri's avatar
      Make sure the kernel doesn't starve from memory during memory erasure. · 552bab73
      intrigeri authored
      We want to set it to the lowest possible value, to maximize the coverage
      of memory erasure. But Documentation/sysctl/vm.txt for
      vm.min_free_kbytes says: "if you set this to lower than 1024KB, your
      system will become subtly broken, and prone to deadlock under high
      loads". With 2048KB I've seen freezes, so let's not modify the kernel
      default (8192KB on x86_64 currently).
      
      Refs: #9707, #10487.
      552bab73
    • kytv's avatar
      Switch from 'service' to 'systemctl' where possible · d83f1f7b
      kytv authored
      d83f1f7b