Winget-AutoUpdate
Winget-AutoUpdate copied to clipboard
[Feature Request]: Digitally sign Powershell scripts
The request
Hello,
We are using Applocker and it blocks running unknown powershell files from %programdata% (c:\programdata usually) where Winget-AutoUpdate seems to install it scripts.
So we get errors like EventId: 8007, EventTime: 2024-02-09T09:02:18Z, Source: Microsoft-Windows-AppLocker, Message: %OSDRIVE%\PROGRAMDATA\WINGET-AUTOUPDATE\FUNCTIONS\ADD-SCOPEMACHINE.PS1 was prevented from running.
Could you please digitally sign your scripts so we could whitelist them using a certificate?
Or is there way to install the software and its scripts automatically under C:\program files\ (where only admins can write by default)? Of course whitelisting them by certificate is preferred option but this could be a workaround.
Thanks,
Is your feature request related to a problem?
No response
Additional information
No response
Sort of a deja-vu. I lost track how many times it was requested.
Copy-pastes from #514
I do not want to be devils advocate here but you can trust file by hash. Understanding the file hash rule condition in AppLocker I wouldn't expect a community-developed project to waste money on signing a single file for little or no profit.
If you have AppLocker in your company, it means that it is managed. The mouse doesn't bite. Going through the wizard to add a single file will take less time than writing in this thread.
Sort of a deja-vu. I lost track how many times it was requested.
Copy-pastes from #514
I do not want to be devils advocate here but you can trust file by hash. Understanding the file hash rule condition in AppLocker I wouldn't expect a community-developed project to waste money on signing a single file for little or no profit. If you have AppLocker in your company, it means that it is managed. The mouse doesn't bite. Going through the wizard to add a single file will take less time than writing in this thread.
And just maybe if this gets requested so often shows how much better solution signing the files would be compared allowing file hashes.
And just maybe if this gets requested so often shows how much better solution signing the files would be compared allowing file hashes.
The product is covered by the MIT license, using it without an additional fee should be a sufficient nod to users asking for additional expenses related to the purchase of a certificate. The moment the author asked for money to collect funds for the purchase of such a certificate, the same mouths that "ask" will fall silent.
Is there any need, that C:\ProgramData\Winget-AutoUpdate
is user writable? Having all scripts/EXEs in a directory, that is not writable by users, makes things much easier with AppLocker.
Isn't the whole C:\ProgramData\ in RWX state for all users? If yes, then C:\ProgramData\Winget-AutoUpdate inherits ACLs from parent container. The only thing that comes to my mind is moving entire WAU INSTALLDIR to $env:ProgramFiles and leave logs where those are right now.
Isn't the whole C:\ProgramData\ in RWX state for all users?
That's correct, Windows standard. Furthermore WAU makes sure every script/folder with scripts is only RX for users
No, in ProgramData normal users get write permission only through CREATOR OWNER permission to the files they have created, and they have another permission to create folders.
They do not have write access to all files there. You should be able to see the examples from screenshot below, probably easier to just test by yourselves.
Users also have permissions to create files in ProgramData.
So even if the Winget-AutoUpdate scripts are read only for users it is not save to create a simple AppLocker rule to generally allow execution from C:\ProgramData\Winget-AutoUpdate
because a user can copy stuff to this directory and execute it afterwards.
Therefore I've asked some posts before if write access to C:\ProgramData\Winget-AutoUpdate
folder is needed at all for users.
You can choose the path for WAU installation https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#advanced-installation -WAUinstallPath
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.