marticliment
commented
8 months ago Hello,
I will need you to open a command prompt window and run the following:
winget upgrade
choco list --outdated
Do any of this commands trigger the UAC prompt?
Closed parlevjo2 closed 8 months ago
marticliment
commented
8 months ago Hello,
I will need you to open a command prompt window and run the following:
winget upgrade
choco list --outdated
Do any of this commands trigger the UAC prompt?
parlevjo2
commented
8 months ago winget upgrade
Name Id Version Available Source
---------------------------------------------------------------------------------------------------------
KeePass Password Safe 1.41 DominikReichl.KeePass 1.41 2.55.0 winget
Opera Stable 105.0.4970.48 Opera.Opera 105.0.4970.48 106.0.4998.16 winget
Mobirise 5.9.4 Mobirise.Mobirise 5.9.4 5.9.11.76 winget
Evernote 10.68.2 evernote.evernote 10.68.2 10.68.3 winget
Python 3.11.5 (64-bit) Python.Python.3.11 3.11.5 3.11.7 winget
Python Launcher Python.Launcher < 3.12.0 3.12.0 winget
UltraEdit IDMComputerSolutions,Inc.UltraEdit 30.1.0.23 30.2.27 winget
NVIDIA GeForce Experience 3.13.1.30 Nvidia.GeForceExperience 3.13.1.30 3.27.0.120 winget
8 upgrades available.
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
choco list --outdated
Chocolatey v1.2.1
Using the list command with remote sources is deprecated and will be made
to only list locally installed packages in v2.0.0. Use the search, or find,
command to find packages on remote sources (such as the Chocolatey Community
Repository).
0 packages found.I think the problem is that wingetui wants to run update.exe self and that it search update.exe in the PATH folders.
where update
C:\Program Files\IDM Computer Solutions\UltraFinder\update.exeIf I remove C:\Program Files\IDM Computer Solutions\UltraFinder from PATH the bug does not appear
parlevjo2
commented
8 months ago I debugged this in procmon.exe and I found that this update.exe was started by powershell.exe, Command line: powershell.exe update self. I can reproduce the bug from the command line by executing command: powershell.exe update self
Date: 26-12-2023 11:29:48,6198861
Thread: 11864
Class: Process
Operation: Process Start
Result: SUCCESS
Path:
Duration: 0.0000000
Parent PID: 6880
Command line: "C:\Program Files\IDM Computer Solutions\UltraFinder\update.exe" self
Current directory: C:\Users\Johan Parlevliet\
Date: 26-12-2023 11:29:46,8912428
Thread: 16216
Class: Process
Operation: Process Start
Result: SUCCESS
Path:
Duration: 0.0000000
Parent PID: 13584
Command line: powershell.exe update self
Current directory: C:\Users\Johan Parlevliet\This powershell,exe is started by wingetui,exe. Instead of powershell.exe update self it probably should be powershell.exe winget update self
Date: 26-12-2023 11:29:46,0688367
Thread: 3736
Class: Process
Operation: Process Start
Result: SUCCESS
Path:
Duration: 0.0000000
Parent PID: 4876
Command line: C:\WINDOWS\system32\cmd.exe /c "powershell.exe update self"
Current directory: C:\Users\Johan Parlevliet\I think the problem is that wingetui wants to run
update.exe selfand that it search update.exe in the PATH folders.where update C:\Program Files\IDM Computer Solutions\UltraFinder\update.exe
WIngetUI should not call any update.exe command, the updater is built-in, it is not an executable...
I will take a look at this
Pandoriaantje
commented
8 months ago If I remove
C:\Program Files\IDM Computer Solutions\UltraFinderfrom PATH the bug does not appear
I can confirm this. I also have some IDM products installed. IDM EasyUpdate gets triggered each time I launch wingetGUI. "update self" is an invalid parameter, so it pops up multiple errors. These products were installed standalone, outside of any 'manager'.
It's actually verry easy to reproduce. have a IDM product installed, and launch wingetGUI or refresh the installed packages/software from within the GUI, and it'll popup multiple instances of "update self".
video: https://github.com/marticliment/WingetUI/assets/4532787/07bd41e1-ec9b-4012-a85d-04a5deb68235
Pandoriaantje
commented
8 months ago My guess is the culprit is in wingetui\PackageEngine\Managers\powershell.py at line 412.
def updateSources(self, signal: Signal = None) -> None:
subprocess.run(f"{self.EXECUTABLE} update self", shell=True, stdout=subprocess.PIPE)
if signal:
signal.emit()this appears to spawn a shell with the "update self" command, which executes update.exe with the "self" argument, from the shell PATH, which IDM adds.
marticliment
commented
8 months ago Yes, this could be it.
I thought I had removed that piece of code, maybe it reappeared due to some incorrect git conflict resolution...
I am going to add a dummy update.exe file to local path and going to test it, but this should be the cause of the issue.
Thanks!
Pandoriaantje
commented
8 months ago maybe this could be fixed with proper quoting? I'm not a python wiz, but chatGPT suggested this change to me:
subprocess.run(f'"{self.EXECUTABLE}" update self', shell=True, stdout=subprocess.PIPE)
marticliment
commented
8 months ago No, the issue here is far more basic: this code shouldn't be here, since PowerShell gallery does not support manually updating package indexes. However, it looks as if the previously deleted code reappeared, possibly the cause of a poorly done git conflict resolution. (this then is my fault) And therefore this command call is running "powershell.exe -Command update self", calling "update.exe" (a file that shouldn't be on the path but it is for whatever the reason) with "self" as a parameter, which the executable ignores.
Pandoriaantje
commented
8 months ago Its indeed weird and unethical on IDM's part. I have UltraCompare, UltraEdit and UltraFinder installed. only Ultrafinder comes with update.exe, yet the updater also finds updates for their other product, but is not supplied in any other product's parent folder. But hey, at least you got a bug/code oversight spotted out of their malpractice. for now i'll just rename the update.exe, I don't use it anyway. Not sure if the path variable is also used for other purposes in the IDM products, so i'll keep that as is.
parlevjo2
commented
8 months ago I am going to add a dummy update.exe file to local path and going to test it, but this should be the cause of the issue.
Easy to test. In C:\Windows\System32 folder do copy "c:\Program Files\Windows NT\Accessories\wordpad.exe" update.exe
And do a refresh in WingetUI and Fresh start of WingetUI.
Also investigate why this update.exe is started 3 respectively 4 times
Pandoriaantje
commented
8 months ago I am going to add a dummy update.exe file to local path and going to test it, but this should be the cause of the issue.
Easy to test. In
C:\Windows\System32folder docopy "c:\Program Files\Windows NT\Accessories\wordpad.exe" update.exeAnd do a refresh in WingetUI and Fresh start of WingetUI. Also investigate why this update.exe is started 3 respectively 4 times
I believe the culprit has already been investigated, and found, just not fixed yet...
The only call to "update(.exe)" (a.f.a.i.c.t.) is in:
def updateSources(self, signal: Signal = None) -> None: subprocess.run(f"{self.EXECUTABLE} update self", shell=True, stdout=subprocess.PIPE) if signal: signal.emit()
anything in the (commandline) path that is named update(.exe) would be called. This could actually be a security risk... any virus/trojan that nests itself in the PATH variable as 'update' would get executed. just pointing out the worst case scenario..
EDIT I had some spare time to look into the code (again i'm no python wizzard), and it seems like all 'managers' share a same template (or this is how I interpret it), and powershell.py controls powershell. As @marticliment mentioned the "def updateSources()" code shouldn't be there in the first place. This wil spawn "poweshell.exe update self", so it wil execute "update(.exe) self", if "update" is in the path. not sure why "poweshell.exe update self" would be called, so i guess that is a leftover from reusing the template? to fix it, (like other manager templates implement), i changed the following in wingetui\PackageEngine\Managers\powershell.py":
def updateSources(self, signal: Signal = None) -> None: pass # Handled by the package manager, no need to manually reload if signal: signal.emit()
These are my personal assumptions, and do not claim it to be true/or correct in any way.
marticliment
commented
8 months ago I am going to add a dummy update.exe file to local path and going to test it, but this should be the cause of the issue.
Easy to test. In
C:\Windows\System32folder docopy "c:\Program Files\Windows NT\Accessories\wordpad.exe" update.exeAnd do a refresh in WingetUI and Fresh start of WingetUI. Also investigate why this update.exe is started 3 respectively 4 timesI believe the culprit has already been investigated, and found, just not fixed yet...
The only call to "update(.exe)" (a.f.a.i.c.t.) is in:
def updateSources(self, signal: Signal = None) -> None: subprocess.run(f"{self.EXECUTABLE} update self", shell=True, stdout=subprocess.PIPE) if signal: signal.emit()anything in the (commandline) path that is named update(.exe) would be called. This could actually be a security risk... any virus/trojan that nests itself in the PATH variable as 'update' would get executed. just pointing out the worst case scenario..
EDIT I had some spare time to look into the code (again i'm no python wizzard), and it seems like all 'managers' share a same template (or this is how I interpret it), and powershell.py controls powershell. As @marticliment mentioned the "def updateSources()" code shouldn't be there in the first place. This wil spawn "poweshell.exe update self", so it wil execute "update(.exe) self", if "update" is in the path. not sure why "poweshell.exe update self" would be called, so i guess that is a leftover from reusing the template? to fix it, (like other manager templates implement), i changed the following in wingetui\PackageEngine\Managers\powershell.py":
def updateSources(self, signal: Signal = None) -> None: pass # Handled by the package manager, no need to manually reload if signal: signal.emit()These are my personal assumptions, and do not claim it to be true/or correct in any way.
Yes, you are right.
When fixing conflicts when merging the PowerShell-testing branch I messed up this, and I did not realize this. This will be fixed on the next release
Please confirm these before moving forward
Describe your issue
After installing version 2.2.0 Each time I press Refresh on The Updates packages tab this program is started 3 times: c:\Program Files\IDM Computer Solutions\UltraFinder\update.exe and asks for administration permission. Also on initial start, then immediately this update.exe is started. I have 3 Ultra* programs installed from IDM Computer Solutions. UltraEdit, UltraFInder, UltraCompare. I have already uninstalled version 2.2.0 and reinstalled it, but still the same behaviour
Steps to reproduce the issue
Press Refresh button
WingetUI Log
Package Managers Logs
Relevant information
none
Screenshots and videos