Skip to content

Bug 40776: Create both a system-wide and a portable Privacy Browser installer

Pier Angelo Vendrame requested to merge pierov/tor-browser-build:bug_40776 into main

Merge Info

Related Issues

Backport Timeline

  • Immediate - patchsets for critical bug fixes or other major blocker (e.g. fixes for a 0-day exploit) OR patchsets with trivial changes which do not need testing (e.g. fixes for typos or fixes easily verified in a local developer build)
  • Next Minor Stable Release - patchset that needs to be verified in nightly before backport
  • Eventually - patchset that needs to be verified in alpha before backport
  • No Backport - patchset for the next major stable

Issue Tracking

  • Link resolved issues with appropriate Release Prep issue for changelog generation
    • No linking, since it doesn't really affect Tor Browser?

Change Description

With this commit, we create two installers for Privacy Browser, instead of one:

  1. the usual installer, that is the same as Tor Browser, for portable mode
  2. an additional installer, for system-wide installations, that requires administrative privileges

Splitting the installers is a sort of cheat, but Windows users are used to having different installers for one mode or the other one.

In particular, the problems we avoid are:

  • adding a checkbox for the portable mode:
    • we cannot add a checkbox to the installation directory page, unless we hardcode a copy of it
    • we should add a new page, and it isn't very elegant
    • to do things properly, we'd need to localize the installer!
    • we need some logic to enable/disable the checkbox
  • nonsense with the required privileges: we don't want to run the installer as admin for portable mode, if possible, so:
    • we could restart the installer with admin privileges, if possible, but only when needed: not trivial
    • we could force portable mode unless the user starts the installer as admin (and tell them to do so, but the UX could be not so great)
    • we stop caring of this, and always run the installer as admin (but there isn't a way for an admin user to start the installer without granting the admin permissions, so bad ux again?)
  • additional nonsense with the privileges: the uninstaller needs to run with high privileges, too!
    • option 1: if we mark the installer as needing admin privileges, the uninstaller is automatically marked, too
    • option 2: we use a custom option to finalize the uninstaller (NSIS 3.08 introduced one, e.g., to automatically sign uninstallers)
    • option 3: we patch the NSIS C++ code

So, the two option cheat seems to be the easiest alternative.

In addition to that, I've cleaned and improved pe_checksum_fix.py:

  • it now uses the with open() as f which is preferred in scripts
  • it accepts the input as an argument, instead of using hardcoded names
  • it overwrites the input, rather than creating an additional one, since we don't need the original one

This allowed to cleanup a mv dance in projects/browser/build 🙂 .

Finally, it renames the Start $which Browser desktop and start menu links to $which Browser. I think they're cleaner, but I can revert the change in case.

The MR includes the commit also from !651 (merged), so this one should be merged first, then I'll rebase this one, if needed.

Merge request reports