1. 29 Jun, 2018 1 commit
  2. 28 Jun, 2018 1 commit
  3. 24 Jun, 2018 1 commit
    • Georg Koppen's avatar
      Prepare build3 · e8c4d33d
      Georg Koppen authored
      We pick up fix for Windows bustage and a macOS reproducibility issue.
      Moreover an update Torbutton version with a new icon gets included, too.
      e8c4d33d
  4. 23 Jun, 2018 3 commits
  5. 22 Jun, 2018 3 commits
  6. 21 Jun, 2018 3 commits
  7. 19 Jun, 2018 2 commits
    • Sukhbir Singh's avatar
      Bug 23561: Fix NSIS builds for Windows 64 · 951b1a7e
      Sukhbir Singh authored and boklm's avatar boklm committed
      This commit adds support for building the 64-bit version of NSIS, and
      also bumps the version to 3.03. Doing this enables us to build MAR files
      in a 64-bit container for the 64-bit version of Tor Browser; see bug
      26363 and bug 24477.
      
      The pe_checksum_fix.py doesn't work in a 64-bit container with the
      bundled python-pefile version so we build its latest version to fix this
      issue. This change is borrowed from commit bb32ec91 and updates
      python-pefile to 2017.11.5.
      
      The Debian package and the patches are no longer required as all changes
      were merged upstream in 3.01-1. (See the nsis changelog in Debian.)
      951b1a7e
    • Georg Koppen's avatar
      Bug 26362: Use old MAR format for update file creation · befc4910
      Georg Koppen authored
      Mozilla switched from Bzip2 to LZMA as compression algorithm for MAR
      files during th Firefox 56. That means esr52-based Tor Browsers don't
      understand LZMA yet. Thus, we still use Bzip2 for the first esr60-based
      MAR files and switch afterwards to LZMA.
      befc4910
  8. 12 Jun, 2018 1 commit
  9. 07 Jun, 2018 2 commits
  10. 06 Jun, 2018 1 commit
    • Georg Koppen's avatar
      Bug 24632: Adapt firefox and tor-browser to new macOS toolchain · e76952c3
      Georg Koppen authored
      After building Firefox we now get a 'Tor Browser.app' instead of a
      'TorBrowser.app'. This patch makes sure the additional whitespace in the
      app name is correctly handled by the build script and the one that deals
      with packaging the final bundle.
      
      We need to ship a fix for the Firefox packaging step as well as
      |./mach package| wants to build the final .dmg in that step, too, which
      breaks: there is no .dmg creation tool available. Setting
      `INNER_MAKE_PACKAGE` to `true` does not seem to work anymore. That part
      of this patch is currently only a workaround to get the nightly builds
      going. We should come up with a better solution that allows us to skip
      that part of the Firefox packaging step on all supported platforms.
      e76952c3
  11. 29 May, 2018 2 commits
  12. 16 May, 2018 1 commit
  13. 03 May, 2018 2 commits
  14. 16 Apr, 2018 1 commit
  15. 11 Apr, 2018 1 commit
  16. 09 Apr, 2018 1 commit
  17. 25 Mar, 2018 1 commit
  18. 24 Mar, 2018 1 commit
  19. 16 Mar, 2018 1 commit
  20. 08 Mar, 2018 1 commit
  21. 24 Feb, 2018 1 commit
  22. 22 Feb, 2018 1 commit
  23. 21 Feb, 2018 3 commits
    • boklm's avatar
    • Georg Koppen's avatar
      Release preparations for 8.0a2 · b3fa8c1c
      Georg Koppen authored
      Changelog update and versions bump
      b3fa8c1c
    • Richard Pospesel's avatar
      Bug 15599: Range requests used by pdfjs are not isolated to URL bar domain · 7db15759
      Richard Pospesel authored and Georg Koppen's avatar Georg Koppen committed
      After much debugging and investigation, it seems that the required
      information needed to drive the first-party domain cannot be accessed in
      the XmlHttpRequest creation path.  The JS context the part of pdf.js making
      the range requests runs with does not have a reference to parent window and
      associated LoadInfo information (which includes the requesting first-party
      domain).
      
      To fix the issue, we can easily disable support for range-based requests
      via the pdfjs.disableRange property.  However, the side-effect here is
      that pages can not be read as they load; the entire pdf must be
      downloaded before it can be read and interacted with.
      
      This patch updates each platforms extension-overrides.js to change this
      pref.
      7db15759
  24. 19 Feb, 2018 1 commit
    • Georg Koppen's avatar
      Bug 25000: Add [System+Principal] to the NoScript whitelist · fefb117a
      Georg Koppen authored
      We need to whitelist `[System+Principal]` for functioning settings
      frames of WebExtensions on the about:addons page. On higher security
      slider levels this is broken otherwise.
      
      To quote Giorgio Maone (see: #25000 comment:14):
      
      "The Tor Browser enforces permissions cascading, and in the Add-ons
      Options window the top frame is about:addons, whose principal's origin
      is [System+Principal]. Since this origin is omitted from Tor Browser's
      version of NoScript mandatory whitelist, the top site by default is
      considered forbidden, cascading down script blocking to the
      WebExtension's subframe."
      fefb117a
  25. 16 Feb, 2018 1 commit
  26. 08 Feb, 2018 1 commit
  27. 02 Feb, 2018 1 commit
  28. 18 Jan, 2018 1 commit