- 14 Sep, 2019 5 commits
-
-
intrigeri authored
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Themes#Documentation says that "Lightweight themes have been deprecated", which explains why our old, custom lightweight theme is ignored. The only options to fix this are: - Create our own theme, get it automatically signed by Mozilla on AMO, download the resulting XPI, and somehow make it available at build time. - Use an existing theme with a GPL-3+ compliant license. I've chosen the latter option: this theme is almost identical to the one we had before. The XPI is 7.7K so I don't think it's worth devising a more complicated solution than just adding it to Git.
-
intrigeri authored
In the Browser Console of the Unsafe Browser, I see: Warning: unrecognized command line flag -DISPLAY
-
intrigeri authored
Now that Torbutton is integrated in Tor Browser (https://trac.torproject.org/projects/tor/ticket/10760), we only have to patch its own localized branding files.
-
intrigeri authored
-
intrigeri authored
Our previous tweaks, when applied to Firefox 68, made it segfault on startup. The layout of omni.ja has changed a lot so let's adapt our code. Besides, there are no localized search extensions anymore so we can simplify things a bit.
-
- 31 Aug, 2019 5 commits
-
-
segfault authored
-
intrigeri authored
-
intrigeri authored
-
intrigeri authored
Terminate GDM's GNOME session after the amnesia user logs in, in order to free memory (refs: #12092) I've heard rumors that we can drop this hack when we switch to Wayland (#12213). We'll see :) We kill it as part of desktop.target, i.e. during the "Applications" phase of the initialization of the GNOME session. We cannot do this earlier reliably: - basic.target is started by "systemd --user" for almost every command run as the amnesia user and may thus be triggered too early, at a time when we still need GDM's processes. - If we do this as part of basic.target, it sometimes happens before amnesia's X.Org has started, and sometimes after that, which causes racy behaviour, weird bugs, and amnesia's $DISPLAY can be either :0 or :1, which breaks our code that relies on that value to be always the same. We're in no rush to kill GDM's GNOME session super early anyway. Note that we keep GDM running while we kill its GNOME session, otherwise, the amnesia user can't unlock the screen: Failed to open reauthentication channel: Gio:DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.DisplayManager was not provided by any .service files Also, we ensure gdm-session-worker does not start new sessions once the amnesia user has logged in, which should hopefully prevent GDM from activating such a session while we want the amnesia's user session to remain active.
- 25 Aug, 2019 2 commits
- 23 Aug, 2019 2 commits
-
-
intrigeri authored
-
intrigeri authored
Sleeping 5 seconds unconditionally harms UX. The assumption here is that: - #9012 was caused by an aufs bug that somehow affects how udev (and the kernel?) monitor /etc/modprobe.d/, and make them need time until they notice that all-net-blacklist.conf was deleted. - The same bug would also affect the "-e" test done by the shell this script runs under. That is, it would affect essentially any process that accesses /etc/modprobe.d/. - So for example, this bug can't be "the inode number of /etc/modprobe.d changed between the time udev started monitoring it, and the time we trigger a replay of the kernel 'add' events". According to the aufs documentation, inode numbers can change when using the noxino mount option, which we do, and actually that's been one of my primary suspects when investigating #9012.
-
- 19 Aug, 2019 2 commits
-
-
intrigeri authored
This will give us UTF-8 support. Note the switch from raw bytes IO to StringIO: the equivalent of what we used to do in Python 3 is io.BytesIO(), but that won't work out of the box: the code we're running prints strings on stdout/stderr, not bytes, and Python 3 knows the difference. So accordingly, remove decoding of the output, since we get a string already. Drop anonym's "showingOnly" patch that was merged upstream :)
-
intrigeri authored
Otherwise, it gets lost (or at least I could not find it). In any case, it does not make sense to print "The error was:" somewhere and the actual error elsewhere.
-
- 11 Aug, 2019 1 commit
-
-
segfault authored
-
- 10 Aug, 2019 3 commits
- 01 Aug, 2019 2 commits
- 27 Jul, 2019 1 commit
-
-
segfault authored
Those are the files installed by the greeter, from the master branch of the greeter repo (commit 2b1facdbe3c4c9f209cdcf3835a9d52a3147b8a8). All files are copied to the same path they are installed at when installing the greeter Debian package, except for: * The tailsgreeter Python package, which is now installed under /usr/local/lib/python3/ instead of /usr/lib/python3, because that's where we put our own Python packages. * The tails-greeter script, which is now installed in /usr/local/lib/ instead of /usr/bin, because this script should not be executed by the user directly, similar to the other scripts in the lib directory. The Exec= path in tails-greeter.desktop is updated accordingly.
-
- 20 Jul, 2019 2 commits
- 14 Jul, 2019 1 commit
-
-
segfault authored
-
- 11 Jul, 2019 2 commits
-
-
emmapeel authored
Currently translated at 17.7% (11 of 62 strings) Translation: Tails/wiki/src/news/version_3.14.1.*.po Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/
-
emmapeel authored
Currently translated at 39.0% (16 of 41 strings) Translation: Tails/wiki/src/news/version_3.11.*.po Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/
-
- 18 Jun, 2019 1 commit
-
- 17 Jun, 2019 3 commits
- 30 May, 2019 1 commit
-
-
anonym authored
This should not be necessary and is just placed here as a workaround until I can figure out the real issue (bug in onion-grater? bug in stem?). When working on the Tor Browser 9.0 migration there were issues with Tor Launcher. It starts and does its initial connection to the control port where it successfully fetches CONFs etc. When clicking "Connect" it successfully sends a few more things and disconnects, only to reconnect immediately later (due to some implementation detail in Tor Launcher). This reconnection fails: [...] /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57472, filter: tor-launcher): -> SAVECONF /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57472, filter: tor-launcher) disconnected: Client closed its socket [ Here comes the reconnect: ] /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57476, filter: tor-launcher) connected: loaded filter: tor-launcher Final rules: [...] Unable to connect to tor. Maybe it's running without a ControlPort? /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57476, filter: tor-launcher) disconnected: client quit ---------------------------------------- Exception happened during processing of request from ('127.0.0.1', 57476) Traceback (most recent call last): File "/usr/lib/python3.5/socketserver.py", line 625, in process_request_thread self.finish_request(request, client_address) File "/usr/lib/python3.5/socketserver.py", line 354, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python3.5/socketserver.py", line 681, in __init__ self.handle() File "/usr/local/lib/onion-grater", line 629, in handle self.controller = self.connect_to_real_control_port() File "/usr/local/lib/onion-grater", line 570, in connect_to_real_control_port stem.connection.authenticate_cookie(controller, cookie_path=global_args.control_cookie_path) File "/usr/lib/python3/dist-packages/stem/connection.py", line 803, in authenticate_cookie auth_response = _msg(controller, msg) File "/usr/lib/python3/dist-packages/stem/connection.py", line 1055, in _msg return controller.msg(message) AttributeError: 'NoneType' object has no attribute 'msg' ---------------------------------------- But if we just connect yet again, it works, hence the workaround. Refs: #16356, #15709
-
- 29 May, 2019 1 commit
-
- 24 May, 2019 1 commit
-
-
anonym authored
Without this e.g. the automated test suite, which will call export_gnome_env() before gnome-shell is running, will have its journal polluted with errors about this. This is not the first time I see this and get worried and waste minutes investigating, so let's just fix it.
-
- 18 May, 2019 3 commits
- 11 May, 2019 1 commit
-
-
segfault authored
-
- 10 May, 2019 1 commit
-
-
segfault authored
-