- 11 Feb, 2016 1 commit
-
-
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
-
- 10 Feb, 2016 3 commits
-
-
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.
-
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
-
anonym authored
E.g. for our custom/undocumented (but so far unused) `--force-net-config` option.
-
- 09 Feb, 2016 8 commits
-
-
anonym authored
The path hasn't existed for a long while, and places.sqlite hasn't been created there for even longer.
-
anonym authored
... instead of polluting the complete environment with it.
-
anonym authored
It feels like it belongs better in the script where we actually start Tor Launcher than the wrapper that makes root invoke it in the way we want. Also, we have to think less about how sudo propagates environment variables so we can simplify its setup.
-
anonym authored
To simplify some paths.
-
anonym authored
... where we have the Tor Browser. For consistency.
-
anonym authored
Let's not pretend the current script is similar to what upstream would use, since it has Tails specific stuff in it.
-
anonym authored
... instead of the crazy workaround we had to use before. It turns out you *can* use -app and -profile together, but only if -profile is given last. It may be that it was fixed recently, because I'm pretty sure it didn't work last time I wroked on this. Also, in /usr/share/TorBrowser/Data/Browser (which is the "default" profile directory relative to the Tor Launcher applocation.ini file) the Caches directory must exist and be accessible for the tor-launcher user even if -profile is used, so we just have to ensure it exists. Will-fix: #7943
-
anonym authored
-
- 08 Feb, 2016 1 commit
-
- 04 Feb, 2016 4 commits
- 26 Jan, 2016 1 commit
-
- 25 Jan, 2016 1 commit
-
-
anonym authored
-
- 22 Jan, 2016 1 commit
-
- 11 Jan, 2016 1 commit
-
-
anonym authored
-
- 10 Jan, 2016 3 commits
-
- 09 Jan, 2016 3 commits
- 05 Jan, 2016 2 commits
-
- 03 Jan, 2016 1 commit
-
-
emma peel authored
-
- 02 Jan, 2016 1 commit
-
- 18 Dec, 2015 1 commit
-
-
anonym authored
-
- 14 Dec, 2015 3 commits
-
- 10 Dec, 2015 1 commit
-
-
kytv authored
Will-fix: 10167
-
- 09 Dec, 2015 4 commits
-
-
Tails developers authored
The script runs `killall sdmem`, which kills itself.
-
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.
-
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.
-
kytv authored
-