marticliment
[BUG] Can't find winget and pwsh (and possibly others) despite them being in the path
Please confirm these before moving forward
- [x] I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
- [x] I have tested that this issue has not been fixed in the latest (beta or stable) release.
- [x] I have checked the FAQ section for solutions.
- [x] This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version
3.3.5
Windows version, edition, and architecture
Windows 11 Enterprise 23H2 x64
Describe your issue
Unigetui reports at least winget and pwsh (7) as missing even though they work well in the shell, thus evidently are in the path mechanism somehow. This is especially annoying because the winget version shipped with unigetui doesn't work either.
Additionally I cannot manually set the path to any of these binaries.
It would probably sufficient to have the setting that is normally just a dropdown allow people to select the binary manually in that case.
Steps to reproduce the issue
Just install and have a look at the package manager settings binary paths for winget and pwsh, winget is showing only the shipped and pwsh shows nothing in the dropdown.
UniGetUI Log
Not available
Package Managers Logs
not available
Relevant information
No response
Screenshots and videos
No response
What I found strange is that in process monitor the process start event does not show a PATH variable in its environment, my gut feeling says that the environment variables are not propagated correctly to the where.exe call
running uniget as a user with admin rights works, and where.exe also has a correct PATH variable there
It would probably sufficient to have the setting that is normally just a dropdown allow people to select the binary manually in that case.
This has been proposed, but rejected, due to security concerns.
running uniget as a user with admin rights works, and where.exe also has a correct PATH variable there
So does it not work when UniGetUI is run as a user, but does as an admin?
It would probably sufficient to have the setting that is normally just a dropdown allow people to select the binary manually in that case.
This has been proposed, but rejected, due to security concerns. How so? Assuming the path mechanism works all that needs to be done additionally is to put it into the path...
running uniget as a user with admin rights works, and where.exe also has a correct PATH variable there
So does it not work when UniGetUI is run as a user, but does as an admin? Indeed. Unfortunately I cannot provide the logs but it shows that the call to where.exe fails, and in process monitor I can see that it does not have any PATH set...
How so? Assuming the path mechanism works all that needs to be done additionally is to put it into the path...
A malicious actor could modify your settings without you knowing to point to their own executable that could run harmful code, which would not be realized and then run - possibly even as administrator - by the program who thinks it will update a package. I think this is partially negated by the secure settings, but Martí has still said he prefers simply having the dropdown, if I remember correctly.
Indeed. Unfortunately I cannot provide the logs but it shows that the call to where.exe fails, and in process monitor I can see that it does not have any PATH set...
That's odd, then, since it should propogate down. Perhaps there's an issue with the code that sets the environment variables?