1. 03 Jul, 2018 1 commit
  2. 01 Jul, 2018 1 commit
  3. 29 Mar, 2018 1 commit
  4. 22 Mar, 2018 2 commits
  5. 14 Feb, 2018 1 commit
  6. 05 Feb, 2018 1 commit
  7. 08 Nov, 2017 1 commit
  8. 24 Sep, 2017 1 commit
  9. 22 Sep, 2017 2 commits
  10. 05 Sep, 2017 1 commit
  11. 08 Jun, 2017 1 commit
  12. 04 Jun, 2017 1 commit
  13. 02 Jun, 2017 2 commits
  14. 01 Jun, 2017 1 commit
  15. 30 May, 2017 1 commit
    • anonym's avatar
      Generate the Tor Browser bookmarks database from an sqlite dump. · 35bdf510
      anonym authored
      Since Tor Browser 7.0a4 (Firefox 52.1.1esr) our places.sqlite symlink
      cannot point to a non-existing file; it must point to an existing file
      that is a valid Firefox bookmarks sqlite database, or else Tor Browser
      will remove the symlink, replacing it with Firefox' default
      places.sqlite.
      
      Will-fix: #12568
      35bdf510
  16. 22 May, 2017 1 commit
  17. 19 May, 2017 2 commits
    • intrigeri's avatar
      Revert "torbrowser-AppArmor-profile.patch: only match own /proc/$pid entries." · b5fc29a4
      intrigeri authored
      This reverts commit 1e8bec50.
      
      For now, the @{pid} tunable matches all pids; see
      /etc/apparmor.d/tunables/kernelvars for details. So it's not worth carrying
      a delta vs. the upstream profile, even though this improvement makes sense:
      better contribute it directly upstream.
      b5fc29a4
    • anonym's avatar
      Partially fix browser bookmarks persistence for Tor Browser 7.0a4. · 9abc143e
      anonym authored
      Apparently this new Firefox will get the realpath of the places.sqlite
      symlink, get its parent directory and create places.sqlite-{shm,wal}
      there -- if the creation of these two files fail, it's like if there
      are no bookmarks, and no new ones can be added (the "Add bookmarks"
      dialog won't even open). So we have to allow the creation of these
      files too.
      
      Unfortunately this is not enough. If the target file of the symlink
      doesn't exist it is interpreted as a corrupt database => the symlink
      is deleted and replaced with a fresh bookmarks database (inside the
      Tor Browser profile, not the persistent directory). So, if you already
      have persistent bookmarks from before it will work, but if enable it
      for the first time it won't work. This will be fixed later, and will
      be documented as a known issue in Tails 3.0~rc1.
      9abc143e
  18. 18 May, 2017 2 commits
  19. 29 Jul, 2016 1 commit
  20. 18 Mar, 2016 1 commit
  21. 14 Mar, 2016 1 commit
  22. 08 Feb, 2016 1 commit
  23. 09 Jan, 2016 1 commit
  24. 19 Nov, 2015 1 commit
  25. 19 Aug, 2015 1 commit
    • intrigeri's avatar
      Refresh Tor Browser AppArmor profile patch. · 77369839
      intrigeri authored
      The old one doesn't apply on top of testing's torbrowser-launcher anymore.
      Our Jenkins job didn't warn us in advance because the changes made in Debian
      were made with quilt patches, and that job only tests Git merging.
      77369839
  26. 11 Jul, 2015 1 commit
  27. 06 Jun, 2015 1 commit
  28. 05 Jun, 2015 1 commit
  29. 04 Jun, 2015 1 commit
    • intrigeri's avatar
      AppArmor: don't allow Tor Browser to access machine-id. · baf42e04
      intrigeri authored
      It was initially added because it was needed for Tor Browser to play sound with
      PulseAudio, but in the end it turns out that this use case works just fine
      without allowing such access => let's tighten thing a bit, and make our delta
      with upstream's profile smaller.
      
      Note that machine-id is currently a per-Tails-version identifier, but depending
      on the outcome of #7100 it may become a per-Tails-boot one.
      baf42e04
  30. 25 May, 2015 1 commit
  31. 19 Apr, 2015 1 commit
  32. 19 Feb, 2015 1 commit
  33. 09 Feb, 2015 1 commit
  34. 06 Feb, 2015 2 commits