-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink installer and how it sets stuff up (reduce need for admin) #10126
Comments
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:
|
Why not detect if valid location and enable functionality no matter what the startup task will have split logic. |
It will not mitigate the vulnerability unless is a location that requires admin privileges to write. |
I don't like the installation in user context. This makes deployment in company environments with sccm (or others) complicated/nearly impossible. |
@crutkas |
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). |
@Cyberdroid1 |
lets use this as the talking point, break work apart from there as i know this is a larger item |
We also want to have a checkbox during uninstallation to remove the settings as well. |
can we maybe close this issue and reconsitute what work is left now? |
Sure. To sum up: we've reworked the installer, fixed some issues and migrated to standard WiX bootstrapper. However, there is still unresolved stuff which doesn't let us to fully transition to per user install, and also we're blocked by dotnet runtime dependency requiring elevation. |
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.
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
.51
.53
Plan discussed: ETA Nov 2021 release
What I’m proposing is a new process that handles
This exe would be called when a user
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.
The text was updated successfully, but these errors were encountered: