Rethink installer and how it sets stuff up (reduce need for admin)

[crutkas]

Right now we have a hybrid of logic between the settings app / runner and the installer. Most is duplicate.

What i think we should do is move most to a common library and have, on uninstall, these be removed, else they are maintained and invoked by the actual application.

• Run at Startup -> we have two modes here, one for admin and another for normal users to prevent UAC prompts on start up
• Reg context menus -> This doesn't require admin rights for image resizer / power rename
• Reg file associates -> come up with way to prompt users on first load to register.
  • this will be must more powerful once the Monaco preview pane comes online
• better user prompts for non-supported scenarios (Example, user installs on Win8.1)

Ultimately, these changes should simplify the installer as well as the upgrade process. Chances are there are a few other items that need to be here as well but i think how we currently handle our installer needs to be rethought as we grow and do even more complex scenarios

Workback schedule

.49

• move all logic to centeralized spot
• move elevation from MSI to EXE (bootstrapper) [multiple UAC elevation prompts during updates #8828]

.51

• Move runtimes to MSI
• Verify HKCU vs HKLM for some of the quirks when running as admin

.53

• No more elevation
• Remove Bootstrapper

Plan discussed: ETA Nov 2021 release

1. Image Resizer context menu
2. PowerRename context menu
3. File reg for file explore thumbnails <- based on settings, looks to need elevation
4. File reg Preview pane items <- based on settings, looks to need elevation

What I’m proposing is a new process that handles

1. Adding context menus
2. File reg for thumbnails
3. File reg for preview panes

This exe would be called when a user

1. Changes a setting that will force us to change
2. When we detect on first time / upgrade we don’t have hooks (dialog to confirm)
3. Uninstall and we have reg’ed hooks
   a. If a user cancels the UAC, we need to validate.

This allows for a single centralized spot for logic, simplifies the Wix installer file, and will allow us to have an easier way to enable the Monaco 150 files.

[enricogior]

One important thing to keep in mind: if we allow to install PowerToys in a user folder (not in the Program Files) we must remove the option to run it as admin because it would open a security vulnerability very easy to exploit.

In order to mitigate the vulnerability we would have to:

• don't load the modules at run time, and link them at build time
• in the runner, validate each external binary signature before running them elevated
• prompt the UAC every time PowerToys starts elevated (aka stop using the scheduled task)

[crutkas]

Why not detect if valid location and enable functionality

no matter what the startup task will have split logic.

[enricogior]

@crutkas

Why not detect if valid location and enable functionality

It will not mitigate the vulnerability unless is a location that requires admin privileges to write.

[htcfreek]

I don't like the installation in user context. This makes deployment in company environments with sccm (or others) complicated/nearly impossible.

[enricogior]

@crutkas
is this issue a tracker for the specifications or for the actual work?
If it's for the actual work, it cannot be done in 0.37 since we have other work that has higher priority.

[prakharb5]

Agree with this issue. Currently when updating, installer triggers the UAC prompt thrice (though the last one seems to be of app). Instead, a single prompt should be used. Say, a process triggers UAC prompt and gets root access, and then it manages and processes the upgrade (deleting files, making change to context menu, run at startup - all 3 by one UAC prompt).

[enricogior]

@Cyberdroid1
what you describe is a different issue and it's tracked by #8828