1. 14 Sep, 2019 5 commits
  2. 31 Aug, 2019 5 commits
    • intrigeri's avatar
      Improve comments. · edc71c6f
      intrigeri authored
      I.e. integrate as code comments all the relevant explanations
      that were in commit messages, in the previous non-squashed branch
      for refs: #12092.
      edc71c6f
    • segfault's avatar
    • intrigeri's avatar
      Fix unlocking the screen. · 6c8cd784
      intrigeri authored
      6c8cd784
    • intrigeri's avatar
    • intrigeri's avatar
      Terminate GDM's GNOME session after the amnesia user logs in, in order to free... · 9e6df451
      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:
      
        Fai...
      9e6df451
  3. 25 Aug, 2019 2 commits
  4. 23 Aug, 2019 2 commits
    • intrigeri's avatar
    • intrigeri's avatar
      tails-unblock-network: only sleep until all-net-blacklist.conf is gone (refs: #16805) · 1527d3c0
      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.
      1527d3c0
  5. 19 Aug, 2019 2 commits
    • intrigeri's avatar
      Test suite: install Dogtail from Bullseye and run it with Python 3 (refs: #16976) · 2ded9055
      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 :)
      2ded9055
    • intrigeri's avatar
      Remote shell: print traceback to stderr so we can see it. · 05d75e85
      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.
      05d75e85
  6. 11 Aug, 2019 1 commit
  7. 10 Aug, 2019 3 commits
  8. 01 Aug, 2019 2 commits
  9. 27 Jul, 2019 1 commit
    • segfault's avatar
      Copy greeter files into config/chroot_local-includes (refs: #16912) · 700b8424
      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.
      700b8424
  10. 20 Jul, 2019 2 commits
  11. 14 Jul, 2019 1 commit
  12. 11 Jul, 2019 2 commits
  13. 18 Jun, 2019 1 commit
  14. 17 Jun, 2019 3 commits
  15. 30 May, 2019 1 commit
    • anonym's avatar
      onion-grater: retry connecting to the real control port. · f74cec4d
      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
      f74cec4d
  16. 29 May, 2019 1 commit
  17. 24 May, 2019 1 commit
    • anonym's avatar
      Make export_gnome_env() exit early if gnome-shell isn't running. · b9e237ae
      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.
      b9e237ae
  18. 18 May, 2019 3 commits
  19. 11 May, 2019 1 commit
  20. 10 May, 2019 1 commit