1. 26 Jan, 2018 8 commits
  2. 22 Jan, 2018 2 commits
  3. 20 Jan, 2018 1 commit
  4. 18 Jan, 2018 2 commits
  5. 08 Jan, 2018 1 commit
  6. 06 Jan, 2018 1 commit
    • intrigeri's avatar
      Pin the AppArmor feature set to the Stretch's kernel one. · 13722c56
      intrigeri authored
      Linux 4.14 brings new AppArmor mediation features and the policy shipped in
      Stretch may not be ready for it. So let's disable these new features to avoid
      breaking stuff: it's too hard to check if all the policy for apps we ship (and
      that users install themselves) has the right rules to cope with these new
      mediation features.
      
      This feature set file will be:
      
       - either removed: once we install an apparmor package that ships its own,
         maintained elsewhere, feature set (probably via Debian#879585);
      
       - or upgraded: to the Buster kernel's, when we move to Buster, iff.
         Debian does not ship any pinned feature set then (refs: #15149).
      
      This commit ports to our build system the changes that are in Buster/sid
      currently, except we include the Stretch's kernel feature set while Buster/sid
      is pinned to Linux 4.14's feature set (the policy in Buster/sid was updated to
      support it). This is exactly what will likely land in the next Debian Stretch
      point release. I'm using a different filename from the one used on Debian, in
      order to make it easier to compare the "upstream" (Debian) file with ours.
      And while I'm at it I'm adding a build-time sanity check that will warn us if
      there's some maintenance work to do on our side.
      13722c56
  7. 04 Jan, 2018 1 commit
  8. 02 Jan, 2018 1 commit
  9. 15 Dec, 2017 1 commit
  10. 29 Nov, 2017 1 commit
  11. 23 Nov, 2017 1 commit
  12. 18 Nov, 2017 1 commit
  13. 14 Nov, 2017 4 commits
  14. 13 Nov, 2017 2 commits
  15. 11 Nov, 2017 1 commit
  16. 08 Nov, 2017 1 commit
  17. 22 Oct, 2017 2 commits
  18. 07 Oct, 2017 2 commits
  19. 01 Oct, 2017 1 commit
  20. 30 Sep, 2017 1 commit
    • intrigeri's avatar
      Force Tor Browser to enable accessibility support even if no a11y feature is... · a3346a75
      intrigeri authored
      Force Tor Browser to enable accessibility support even if no a11y feature is enabled in GNOME yet (refs: #14752, #9260).
      
      My understanding of the code in accessible/atk/Platform.cpp is: if this envvar
      is not set, Firefox will check via D-Bus at startup if accessibility is enabled
      in the Desktop, and if it's not it'll permanently disable accessibility,
      which breaks use cases like starting the screen keyboard or screen reader
      *after* Tor Browser.
      a3346a75
  21. 25 Sep, 2017 2 commits
  22. 24 Sep, 2017 1 commit
  23. 22 Sep, 2017 2 commits