[FEATURE REQUEST] Specify package manager location/path

[headquarter8302]

Please confirm these before moving forward

• [X] I have searched for my feature proposal and not found a work-in-progress/duplicate/resolved/discarded issue.
• [X] This proposal is a completely new feature. If you want to suggest an improvement or an enhancement, please use this template

Describe the new feature

In my install of WingetUI, NPM is not found, and the PowerShell Gallery uses the older version of PowerShell (PS5). I would like to change the location/path of these providers.

Describe how this new feature could help users.

One can specify newer versions of these and/or fix nonstandard installations, in my case, my NPM install is nonstandard so a lot of programs depending on it needs manual tweaking. CLI switches that can override the location of providers also help.

[mrixner]

I think this is subject to the same pitfalls as #3038, right?

[marticliment]

Yes, it is the same thing. It would be very easy to set a custom executable and trick the user into running something as administrator.

[headquarter8302]

@marticliment Do you have plans regarding this? Or do feature requests that require arbitrary user input into the command line execution process will be dropped?

[marticliment]

What I am thinking I will do is to create some kind of special settings that can only be enabled or disabled with administrator rights, and I would lock this dangerous features with a toggle that would require an UAC prompt to be enabled. Then, a potentially malicious agent wouldn't be able to change said settings without notice, as they would require admin permissions.

[mrixner]

This could also be extended to allowing you to set a custom path to any executable UniGetUI requires, and CoreTools.Which could just use the value of this setting.

[mrixner]

This could also be extended to allowing you to set a custom path to any executable UniGetUI requires, and CoreTools.Which could just use the value of this setting.

[marticliment]

I don't think it would be positive to allow the user to change every single executable... I think it could give more headackes than advantages.

[Raizanad]

I admit before hand, I don't know why you guys are so overly careful about this because I'm somewhat ignorant about cyber security - but seeing that this boiled down to local access and locally compromising a system, I don't know why behave like you could step on egg shells when the possibilities are endless to attack (given the surface area of someone with physical access to a device).

But anyway, I came here because I have this issue where UnigetUI doesn't detect Chocolatey because I set the installation directory to an alternate drive. You are the smart guys - so I don't know if there is an easier solution to Choco specifically - but as part of the Chocolatey install in a custom directory you set a user variable name ChocolateyInstall. Could UnigetUI simple detect if choco.exe is in said directory? Or the work around is, as an user, pasting choco.exe into the desired location by UnigetUI meanwhile?

My tone, and the way I text, may make you think I'm being condescending but I assure you I'm not. Thank you for the tool, which I downloaded from the microsoft store (would have never known it existed otherwise, so thank you for the multiple download places). I just came to say this because I just reinstalled Choco and realized it is not found by UnigetUI.

[marticliment]

But anyway, I came here because I have this issue where UnigetUI doesn't detect Chocolatey because I set the installation directory to an alternate drive. You are the smart guys - so I don't know if there is an easier solution to Choco specifically - but as part of the Chocolatey install in a custom directory you set a user variable name ChocolateyInstall. Could UnigetUI simple detect if choco.exe is in said directory? Or the work around is, as an user, pasting choco.exe into the desired location by UnigetUI meanwhile?

If you have chocolatey on your path, it should get picked by UniGetUI. However, the ChocolateyInstall variable is not used to detect chocolatey.

but seeing that this boiled down to local access and locally compromising a system, I don't know why behave like you could step on egg shells when the possibilities are endless to attack (given the surface area of someone with physical access to a device).

My concern is that it would be very easy to escalate privileges via UniGetUI, just by changing an executable and letting the user elevate an operation via an UniGetUI UAC Prompt, which would appear trustable for the user.

[headquarter8302]

@marticliment What variables/methods does UniGet use to detect each package manager's location? Perhaps we can manually stub them to the correct or preferred location without doing changes to UniGet itself, and then document it on the repo's wiki

[mrixner]

The program locates the package managers based on the PATH environment variable. You should be able to convince UniGetUI to locate any custom installs by adding the directory to the user or system path, and then fully restarting UniGetUI.

[Raizanad]

If you have chocolatey on your path, it should get picked by UniGetUI. However, the ChocolateyInstall variable is not used to detect chocolatey.

Something may have changed about chocolatey behavior then? I checked my environment and choco automatically added to the system path, their bin folder (using the installation that defaults to elevated console, which to be honest I don't like and wanted to avoid - but the non elevated installation supposedly only allows to install 200 ish packages in total, this is off topic to this issue but does UnigetUI prefer the non-privileged installation and you know if that installation works for everything despite chocolatey information pages?) instead of the user path so I guess that is the problem.

Thanks for letting me know how to fix that. Just throwing this out here so you know it may be a problem for other users expecting it to "just work".

My concern is that it would be very easy to escalate privileges via UniGetUI, just by changing an executable and letting the user elevate an operation via an UniGetUI UAC Prompt, which would appear trustable for the user.

Had a flashback for a time I set my UAC to have password protection for admin elevation, now I understand why you are worried - got way too used to no prompt or just clicking accept. Thanks for explaining it to me.

Edit: Added to my user path, restarted, choco still not found. The package manager points to "C:\Program Files\UniGetUI\choco-cli\choco.exe" which does not have choco.exe, I installed from the microsoft store if it matters.

Edit 2: Clicked "Use system chocolatey" and it was detected. Hope this helps in any way if another user is lost. Thank you guys for your work.

[marticliment]

but the non elevated installation supposedly only allows to install 200 ish packages in total

I have never heard of this, in and all my testing with Chocolatey through UniGetUI I have always gone non-elevated, and never had any issues.

does UnigetUI prefer the non-privileged installation and you know if that installation works for everything despite chocolatey information pages?) instead of the user path so I guess that is the problem.

Yes, because having chocolatey on an elevated folder will require an UAC prompt for every single operation, while running it from a non-admin folder will lead to an error when an app requires admin permissions. However, UniGetUI detects that and automatically relaunches the process with administrator permissions.

[Raizanad]

Regular Installation

1. First, ensure that you are using an administrative shell - you can also install as a non-admin, check out Non-Administrative Installation.
2. Copy the text specific to your command shell below.

Non Administrative Install (Non-default option, same as installing in another directory)

From that page:

WARNING

This option should be a last resort and is considered to be a more advanced scenario - most things you do on Windows require administrative rights, especially surrounding software management, so you are going to be limited even in packages you attempt to install. If you are using the community package repository, there are over 200 packages you can install from the community repository without administrative permission - see https://community.chocolatey.org/packages?q=id%3Aportable+tag%3Aportable.

I will probably reinstall it as User Chocolatey and test because I wasn't happy about them requiring admin globally. Thanks you, yet another time.