Silent install of "winget install git.git" is not working

[jarrettgsmith]

Environment

Windows Package Manager v0.2.10191 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.18363.1440
Package: Microsoft.DesktopAppInstaller v1.11.10191.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Issue

I am trying to use winget install to install git remotely. When running through a remote session the install hangs because I suspect the installer is waiting for an interaction as it has not gone silent. When I run the silent mode on a local powershell with administrator I get the dialog pop. How can I guarantee silent mode for all potential apps?

I have tried...

winget isntall git.git -h
winget isntall git.git --silent
winget isntall git.git /silent
winget isntall git.git /s
winget install --id Git.Git -e -h
winget install --id Git.Git -e --silent

The dropbox link shows my winget --info as well as the install command failing to run silently and popping up the installer dialog. I am using a powershell in Administrator mode. Eventually I want this to work over a remote session but Im surprised to run up against this immediately. I also tried Notepad++ with the same issue.

Screen Capture

https://www.dropbox.com/s/wwvl068kfvx98y1/winGetInstallSilentIssue.png?dl=0

Thank you,

Jarrett

[jedieaston]

Is SmartScreen enabled on the target machine? If it is disabled, the prompts appear under certain scenarios regardless of what flags are passed to winget (since it's Windows putting them up, not winget).

#703 has some discussion of this issue, but the problem should have been fixed in the last release of winget (which you have)...

[jarrettgsmith]

So I checked SmartScreen settings on all systems. They were all turned off but a few of them had a warning link to the top right of the toggle button that I clicked which popup up a security dialog asking me to confirm. Once I did this I clearly confirmed winget isntall git.git --silent worked on one computer. Then I did the same check on another computer and it didnt fix the issue. I noticed the user interface for this section was slightly different on each computer - so I updated everything to 20H2.

So now I have all systems up to date but 1 computer still forces the popup. Here is an image of the security toggles and the shell output.

As well I just tried turning off the toggles for Edge and the MS Store Apps but still have same issue.

Thanks for you help.

[jedieaston]

On that system, you need to check "Check apps and files" for the security warning to go away. If Windows checks the file against SmartScreen, it is sure enough that the file isn't malware so it doesn't have to ask you.

Edit: it's worth noting that if you are doing this on several machines, these settings can be centrally configured through GPO/MDM: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-available-settings#group-policy-settings

[jarrettgsmith]

Oh wow you are correct. However on the other two systems that checkbox is off. Any ideas what the difference might be? Will check next what happens when I normalize everything.

As well thanks for the tip - yes this is scaling up to 15 new systems so I really appreciate the pointer. Thanks for making winget just found out about it a few days ago and Im really excited to tell our community about it.

Edit: I guess you already mentioned the flags passed along to winget aren't necessarily in sync with the user interface. The solution therefore would be to turn them off and on?

[jedieaston]

"Check apps and files" means that Windows sends a signature from the file to Microsoft to see if it is malicious before opening the file, and in 20H2 they broke this out from the other SmartScreen settings to make it more clear what is going on I think (although someone may know more about it than I do).

The flags passed to winget don't control SmartScreen, it's a different application (and if passing silent to winget caused SmartScreen settings to change that would break a lot of stuff in corporate environments). The settings in the Defender control panel should be what is being applied (and will be greyed out if you use GPO instead).

[denelon]

@jedieaston you seem to be familiar with Group Policy. Would you mind taking a look at some of the policies for the Windows Package Manager? #154

I think we're going to rename them to be more generic "App Installer" since that is what we ship in, so "Windows Package Manager" might become "App Installer" for the policy titles, but the descriptions are pretty close to what we're thinking.

[denelon]

@jarrettgsmith we haven't determined the best path forward for remote execution. Many installers require UAC or have some sort of dialog box. I think remote scenarios may require some additional work in the manifest and the client. I don't know if anybody has created an Issue to address remote scenarios off the top of my head.

[jarrettgsmith]

Ok good to know. Hopefully this will catch on eventually.

[agowa]

Just for the record, going into internet options and allowing unsafe files to execute is currently the only way?

[jedieaston]

If SmartScreen is disabled or otherwise unavailable on the system, yes. But you should enable SmartScreen, it's safer.

[agowa]

@jedieaston: I already disabled SmartScreen, that alone didn't work around this problem...

[jedieaston]

@agowa338 The problem is being created by SmartScreen being disabled. Either enable it (which is what you should do) or set the setting that you had in your screenshot.

[agowa]

But when I had SmartScreen enabled I saw the same issue...

[jedieaston]

Can you send a screenshot of your SmartScreen settings?

[agowa]

winget upgrade Vim.Vim

winget upgrade Ubisoft.Connect

[jedieaston]

Check the box that says "Check apps and files" and try it again.

[agowa]

@jedieaston but then it'll communicate every executable to azure, or am I misunderstanding that feature?
This would be a huge concern. On the one hand, it would be a GDPR concern as it would allow tracking what and when a user opened something as well as exfiltrating data about in-house developed applications...

[jedieaston]

It communicates newly downloaded installer names, URLs, and hashes to Microsoft. If your executable names being anonymously sent to Microsoft is a breach in your security strategy, I'd reevaluate (why are your executable names a trade secret?).

But if you disable SmartScreen, Windows doesn't know if a executable is trustworthy or not so it'll pop up that "Open File - Security Warning" box every time so you know its running a new executable from the internet (unless you go and turn it off, which if you don't have SmartScreen I probably wouldn't). If you are downloading stuff from your internal network, you can tell Windows to the "Trusted Sites" list in Internet Options so it doesn't show the warning (you can also do this via GPO).

[agowa]

is a breach in your security strategy

It's not a security thing, but a compliance one... And having the URL submitted for example could also reveal internal server names. Then if you're a software company, the installer name could exfiltrate information about upcoming products, services, or customers... And this could lead to compliance and NDA violations...

Also to stay on topic, my expectation as a user of winget-cli would be that files it pulls are already "prechecked" and because of the contained sha256sum don't depend on SmartScreen and that winget-cli just removes the ZoneIdentifier (unblocks the file) if the sha256sum (InstallerSha256 from within the yaml file within the winget-pkgs repo) matches the expected one.
This would also cover non signed executables and extend the safety warranty to them as well as allowing for Winget to work with internal reports.
Basically outsourcing the scanning of the executable to the repository server (this could even be done within the pipeline when a new merge request is submitted)...

[fabienr]

But if you disable SmartScreen, Windows doesn't know if a executable is trustworthy or not so it'll pop up that "Open File - Security Warning" box every time so you know its running a new executable from the internet (unless you go and turn it off, which if you don't have SmartScreen I probably wouldn't). If you are downloading stuff from your internal network, you can tell Windows to the "Trusted Sites" list in Internet Options so it doesn't show the warning (you can also do this via GPO).

ApplyMotwIfApplicable(dest, URLZONE_INTERNET);

In brief : Why did you choose to completly ignore internet setting and call "ApplyMotwIfApplicable" to zone 3 on every single download ? ([CORE] Started applying motw to C:... with zone: 3) / src/AppInstallerCommonCore/Downloader.cpp

Some explanation regarding my use case.

I just discover winget-cli a week ago and fall in love with the clear and simple yaml file description for each package. I start writing a small python script which update the git repo, extract yaml files based on a configurable list and then each installer which are put in a intranet website (as winget does not support UNC path for installer - which sadly make standalone installation impossible but note I did not try to point it to a local hard drive). All those manifest are then rewritten with the intranet URL and put in a internal share. Sadly I did not manager to implement a local winget repository but I may thanks to the REST API (which looks easier to learn than the msix). As winget does not allow post-install configuration like other package management I still need something on top of it to deploy configuration so I finally use an other tool which run winget install with -m and point it to my updated manifest which contain internal url.

We have a very low bandwith and we strictly disable internet access (anything, even ntp is internal). I did not try to inspect network traffic neither I searched on internet in order to add exception for smartscreen traffic. When I first try it I change internet settings so my internal url is in Zone.Identifier 2 (internal website). I was thinking it is the solution but now I think this was due to coincidence as I also authenticate myself on our internet portal to run Windows Update without WSUS. Or maybe something else change with 20H2 update.

As you may imagine I become crazy (why did this work some days ago) and start searching. I thinked this was due to my registry tweek to automate the internet setting configuration during initial winget install ... I remove those registry key and start testing different zone and I slowly learn ... Finally I'm a little disapointed because winget choose to set downloaded file to zone 3 just after downloading. Why did you choose to completly ignore internet setting and call "ApplyMotwIfApplicable" to zone 3 on every single download ? ([CORE] Started applying motw to C:... with zone: 3)

From what I understand, if defender and smartscreen are enable they will check the file even from trusted zone or intranet zone so I see no benefit into setting the zone manually in your source code. What happens is that people are forced to use smartscreen or to disable a security feature on zone 3 (or even worse as you may find on internet). From my point of view, disabling security by default is a no way. You remove the ability for administrators to configure this feature and to allow a list of source (based on softwares manifest) or an internal mirror like I'm doing.

Please, can you reconsider this feature and rely on Windows to set the good zone or even like I found in discussion, just unblock the file as it already passed sha256 validation and the corresponding file may already be checked during manifest import or whatever process you have.

I will look for the corresponding commit message to further understand this choice, maybe you can point me to it. For today I'm done.

Regards and thanks for this very nice project !

[denelon]

@fabienr when the installer is downloaded, it's coming from zone 3. After the hash is verified, it's modified to zone 2.

[fabienr]

Thanks @denelon, I was reading more comments and more code in the meanwhile. Looks like I will not sleep without a solution (no, realy this is my last comment today). I'm loocking further now. Thus I read the https://github.com/microsoft/winget-cli/releases/tag/v0.2.3162-preview.

Here is what we do when downloading and executing an installer:
Always set "Mark of the Web" with ZoneIdentifier URLZONE_INTERNET(3) when downloading the installer.
Verify the installer SHA256
If the hash does not match: Leave "Mark of the Web" at URLZONE_INTERNET(3)
If the hash matches:
If the installer is from a trusted source, modify "Mark of the Web" to ZoneIdentifier URLZONE_TRUSTED(2)
If the installer is from an untrusted source, call Attachment Execution Service to trigger anti virus and determine ZoneIdentifier

I move my internal website to zone 2 (trusted) instead of 1 (internal) sorry if I'm confused with 1/2/3 ...
When I download it from edge there is no problem but in fact the file have no zone at all.

PS C:\Users\Administrateur\Downloads> Get-Content .\AutoIt.3.3.14.5.x64.exe -Stream Zone.Identifier
Get-Content : Impossible d’ouvrir l’autre flux de données «Zone.Identifier» du fichier «
C:\Users\Administrateur\Downloads\AutoIt.3.3.14.5.x64.exe».

Wherase the file downloaded from winget (which I delete myself before runing install) have zone 3

PS C:\Users\Administrateur\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet> Get-Content .\AutoIt.AutoIt.3.3.14.5.exe -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3

2021-06-14 23:38:02.918 [CLI ] Installer hash verified
2021-06-14 23:38:02.919 [CORE] Started applying motw using IAttachmentExecute to C:\Users\Administrateur\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\AutoIt.AutoIt.3.3.14.5
2021-06-14 23:38:05.208 [CORE] Finished applying motw using IAttachmentExecute. Result: 0 IAttachmentExecute::Save() result: 0

So it looks like winget did not identify my website correcltly as the flag InstallerTrusted is not set ?
if (WI_IsFlagSet(context.GetFlags(), Execution::ContextFlag::InstallerTrusted)) { Utility::ApplyMotwIfApplicable(context.Get<Execution::Data::InstallerPath>(), URLZONE_TRUSTED); } else if (WI_IsFlagSet(context.GetFlags(), Execution::ContextFlag::InstallerHashMatched)) { const auto& installer = context.Get<Execution::Data::Installer>(); HRESULT hr = Utility::ApplyMotwUsingIAttachmentExecuteIfApplicable(context.Get<Execution::Data::InstallerPath>(), installer.value().Url);

I have to further read the source code to understand how the flag is set, should't it be set based on internet setting ?
if (context.Contains(Execution::Data::PackageVersion) && context.Get<Execution::Data::PackageVersion>()->GetSource() != nullptr && WI_IsFlagSet(context.Get<Execution::Data::PackageVersion>()->GetSource()->GetDetails().TrustLevel, SourceTrustLevel::Trusted)) { context.SetFlags(Execution::ContextFlag::InstallerTrusted); }

Then I do not understand what ApplyMotwUsingIAttachmentExecuteIfApplicable is doing but I guess it changed nothing to the zone as there is no further result for ApplyMotwIfApplicable neither for IZoneIdentifier. Should I do something to refresh / apply my internet settings ? Actually what is a trusted zone from winget point of view ?

[fabienr]

Just to clarify, I'm seeing the same security warning as others comments and I'm not able to silently install packages with winget. This is not related to any specific manifest but rather to the way I mirror the winget repository and internalise the deployment.

winget --info
Windows Package Manager v1.0.11451
Copyright (c) Microsoft Corporation. Tous droits réservés.
Windows: Windows.Desktop v10.0.19042.1052
Package: Microsoft.DesktopAppInstaller v1.11.11451.0

After reading more code, even if I'm not used to cpp. The source check is not checking the installer url but rather the source from which the manifest came from.

1. I'm using "-m" to install from a local manifest
   In this case, I guess GetSource() return nullprt as the manifest did not came from any source. Am I just ?

2. If I try to implement/use/configure an internal source repository (is there any implementation I can use ?)
   Only "https://winget.azureedge.net/cache" and "https://winget.azureedge.net/msstore" are trusted by winget. Right ?

3. As smartscreen is disable (I have to try with this feature enable), or, maybe, if I don't have internet access
   The Attachment Execution Service which trigger anti virus and determine ZoneIdentifier do not report any error but still consider the executable as comming from Internet thus the Zone.Identifier does not change. I'm not sure if this step should change the Zone.Identifier but at the end Windows security feature prevent installer execution as it was not able to verify its footprint with smartscreen. Is it normal the Zone.Identifier does not change even after a successfull anti-virus validation ?

Actually there is no easy solution for my use case which is standalone offline deployment.

• Is there any plan to mirror public repository and even installers (internal mirror - not sure about licence if this is considerd as redistribution clause) ?
• May I suggest you change the Zone.Identifier after antivirus checks if there is no error ?
• May I suggest you check the installer source url againt internet settings to identify the correct Zone.Identifier ? (after antivirus checks maybe or before to qualify the source as trusted ... then what about local manifest without source ...)

The second point may be the easiest one but this depends on your security policy (which I understand but still I think you prevent/ignore Administrator settings).
For sure there is other solution, what do you think should be done even if standalone offline installation is not a priority feature ?

I'm going to to workaround this issue with $env:SEE_MASK_NOZONECHECKS=1 to make progress until there is a proper solution.

[denelon]

@fabienr

1. I believe that is correct, we do not treat the "local" filesystem as a source.
2. have you taken a look at the REST API?
3. I'll talk with the engineering team, and the security team to look at all of the implications. We may need to look at adding some features for this scenario.

[jedieaston]

Is there any plan to mirror public repository and even installers (internal mirror - not sure about licence if this is considerd as redistribution clause) ?

This shouldn't be too hard to add on in a REST source implementation, I was thinking about a similar use case but am waiting for a way to deploy the sample restsource so I can mess with it. The redistribution rights internally shouldn't be a problem, SCCM does it all of the time. You just can't (or shouldn't) make the mirror public without permission from the copyright holders.

[fabienr]

@denelon
I guive a quick look on REST API. Looks promising. I have no knowledge about C#, Azure, Visual Studio and all those full feature envs but it looks like the database layer depends on Cosmos DB which depend on Azure thus online then I will not be able to use it internaly even if I manage to run it with Mono. I saw you and @jedieaston talk about the database layer which could be abstracted and allow, as exemple, a mongodb backend.
In all case, for standalone / offline deployment, winget-cli should provide a solution to trust an other repository, or apply administrator settings to identify known url installer or just relax the Zone.Identifier (zone 1 or 2 or just unblock the file, remove the identifier).
What I have done is easy scripting and it can even be easier without the need to host installers on a local website (which also need a valid https certificate if I did not mess things during my test). Initially I wanted to bring all of these into an usb hard drive with simple powershell scripts, one to install winget and others to install a list of manifest based on profile you define when you setup your standalone folder with my python script. Then you may also be able to share this folder with correct persmission and run those script to deploy and update packages on a regular basis. This can be seen as a poc for a feature which may be added to winget, let's say a new command named clone. Unfortunatly this is not possible as installer url must be http and this will also break the winget security design by allowing an untrusted hard drive which is not safe.

@jedieaston
What is your use case ?
Initially I started with chocolatey but this still is a lot of handwork with the free version as it's almost impossible to parse and extract the installer to internalise it. With winget it's easy to make a script and I have something which will work if I manage to bring all piece together (even a standalone hard drive if I manage to run a portable web server and make things work without https). Note that for now I'm relying on chocolatey which run winget internally but this can easily be changed to be standalone with simple powersheel script, I just choose to use chocolatey to deploy my configuration and tweeks with powersheel and also benefit from the time I spent learning it as it also could help me in some scenario.
But remember, if you internalise installer and repository, it's at your own risk and, actually, there is a reason why it's not so easy to implement as it's inherently insecure. As an exemple, the application should check the sha256 with a signature (or the whole manifest but then you cannot tweek it which is also a need in some case and maybe if someday we can also do post-install configuration) from the official repository to ensure the original installer and your repository was not altered both, even in your local repository which may be far less safe than the actual security measure implemented by the official repository. For sure if you then want to deploy an unofficial package or an internal application, it looks like this tool is not intended for you but still winget can allow administrator to configure that. Note this does not prevent testers from runing their own package as they should not need silent installation in this case.

Thanks you both for your answers ... but did you understand why others have this smartscreen problem ? Which have already been fixed for the official use case.

While the client should be perfectly functional, we are not ready to provide full support for clients running outside of the official distribution mechanisms yet. Feel free to file an Issue, but know that it may get lower prioritization.

If it's a real bug then this issue may have a higher priority. Maybe at least bring more documentation so you can fix it yourself if the problem came from your environnement.
@agowa338 and @jarrettgsmith, can you help me understand what happens on your use case ? You really try official winget realese without tweeks ?

Can you try with "winget install --verbose-logs ..." and look what happens in the last log from ... \ AppData \ Local \ Packages \ Microsoft.DesktopAppInstaller_8wekyb3d8bbwe \ LocalState \ DiagOutputDir ?
You should see two lines "[CORE] Started applying motw to C:... with zone: X". The first one is from the initial download ... X is 3 (internet zone). To be on the safe side, imagine a security breach (even from your internal setup) where you get the wrong file with invalid sha256 then if for any reason this file is not removed from your file system (which winget do immediatly in this case, if I remember correclty) and get run by something else ... smartscreen can save your ass. But if you disable it or have problems during validation process, then you have to confirm you run it at your own risk thus you get the security warning. I never see the second one but I guess the zone X is 2, otherwise this mean somehting is broken with the source trusted level or you do not use the official repository. By doing this, I think winget rely on your configuration which should not require smartscreen as your file is now identified as coming from a trusted zone. Actually, this is more or less the expected behaviour from @agowa338 and is exactly what is implement with trusted source (official repository) as the file even don't go through an anti-virus validation (at least not from winget itself).

Also to stay on topic, my expectation as a user of winget-cli would be that files it pulls are already "prechecked" and because of the contained sha256sum don't depend on SmartScreen and that winget-cli just removes the ZoneIdentifier (unblocks the file) if the sha256sum (InstallerSha256 from within the yaml file within the winget-pkgs repo) matches the expected one.
This would also cover non signed executables and extend the safety warranty to them as well as allowing for Winget to work with internal reports.
Basically outsourcing the scanning of the executable to the repository server (this could even be done within the pipeline when a new merge request is submitted)...

When the security window pop up, keep it open and go check which zone your file have. When this happen you already pass all the security measure implemented by winget. One way to know the zone identifier is with a powersheel command "Get-Content your_file.type -Stream Zone.Identifier". The installer is located in ... \ AppData \ Local \ Packages \ Microsoft.DesktopAppInstaller_8wekyb3d8bbwe \ TempState \ WinGet.

[ZoneTransfer]
ZoneId=X

Maybe someone can confirm this path is the acutal installer winget run ?
Finaly in which zone are you ?

It looks like all reports talk about normal online installation from trusted source. If they don't, I clearly want to know how to implement my own repository and change the source ^^
Maybe Windows now require smartscreen even from a trusted zone (level 2) ?
This option can be configured from advance setting of the zone as you can see in this thread, but the option is not visible in intranet neither in trusted and I cannot tell if Windows remove it from level 1 and 2 as I did not check before I update.
You can also change this with a GPO to configure internet settings and I also check my registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones about those keys (Enabled: [1806=0] - This setting enables the Launching of Applications and Unsafe Files, in the specific zone) as I was not able to (at least) read the configuration from the graphical interface. So I guess someone can mess with this option even on Zone 1 and 2 but as a common user you will never now it as it's not visible in your zone settings.
May a GPO expert confirm or test if it really change the zone 1/2 behaviour ?

@denelon, I hope this will helps the engineering team, and the security team. If the intent is to have a silent install with a deterministic behaviour then, sadly, it looks like winget can't rely on the zone identifier as some GPO may change it (except if I misunderstand something). Maybe @agowa338 and @jarrettgsmith are in this case, can't tell you but I imagine this will happen if a GPO can change this behaviour. Otherwise may I suggest an entry in a future faq like "Why did I get a security warning while I wanted a silent install" ? Note I did not had this exact case but I'm sure a clear answer explaining the intended behaviour and how winget seculry install things by default may benefit users in many cases. Not sure if it's woth mentionning the workaround with a local env variable but if it prevent people from changing the zone 3 settings ...
Moreover, I think the added anti-virus check is nice because winget don't rely on the anti-virus setting as some people may disable permanent scan to gain some performance. For the same reason, I think that winget can't rely on the zone identifier to bypass smartscreen (it's a setting which should be enforced just like the antivirus which is enforced in the other case).
Please remember I suppose a GPO can change this security feature in windows. For sure this will not help my use case as I don't want to use the official repository but this can help in any case, mainly if someone change the source code itself (which may be my next move after setting up an internal repo) or the settings to be more paranoid about local share which contain executable and may be considered as Intranet Zone automatically (just a supposition but somehting I must try in my env : prevent execution from intranet share or ask for confirmation just like internet zone). If winget is the one installer/executable source of trust, this may even be recommended or by default in the future.
I think it's also worth mentionning the lack of a signature (as describe earlier to @jedieaston). Somemone may also imagine a case where the executable is patched and the trusted source get change to something else, basically, trusting a string in a executable does make no sense to me, it should be configurable (actually it is if you patch your binary) or not trusted at all. What's nice with signature is that you already have a chain of trust and you can rely on it being already installed securly in your operating system which mays not require internet except if you want higher security with revocation and so (OCSP ? it's not my confort area). You can still add your own certificate in the store but winget can also bundle its own certificate and also perform its own binary signature check. Actually I don't know if Windows enforce digital signature on executable to prevent unwanted execution on patched binary and if it's the case, the string in the binary should be safe then. I also think the only way to make it safe as the binary self check is insecure by design is to rely on both solution with an internal certificate to enforce the repository trusted installers and an external one to enforce winget binary integrity just like when you initialy download it from an htpps trusted source.
The idea is to sign installer and not manifests so the source is not taken in consideration and people can do whatever they want if they use the original installer trusted by the official winget release. I guess this solution will both meet security design and users expectations. On top of that, each source must be implemented in https so an administrator can add its own repository and benefit from the https trust of manifests from the source. The administrator just need to add the source.

Regarding the workaround, thanks to @jedieaston and @svenmauch to mention it. I may have spent hours to discover SEE_MASK_NOZONECHECKS and the initial issue is closed.

[fabienr]

@denelon, @jedieaston

This is how I solve my use case with both Winget and Chocolatey software but really it would not have been possible to realize this software without Winget! Thanks a lot!

As I did not test it from scratch again, you may find some problems but I think it should work. My address is in the source code license. The hard part is the internal website setup which must point to the installers directory. Except that, just follow the readme, it's very easy to setup.
chocowin.0.1.zip

Hope this helps and maybe we can take some idea there and bring them into real cpp code. Until then, if some peoples are interested we can still open a repo for this small script.

Sorry if for any reason I should not have sent it there. I just want to give back in case someone find it helpful.

[ShadowEO]

Having this same issue with Winget v1.0.11451 on build 21390. It worked fine previously, but now unless I have the env variable added, I get stuck with a Zone Identifier issue, says that my internet security settings have prevented the application from running and I've made no changes to any of those settings, nor has any program installed (I reset IE settings to make sure), or any GPOs as my machine is not managed and no policies are defined.

Only just noticed when I tried to do a winget upgrade --all, and then when that failed, tried to do a single application.

[jedieaston]

@ShadowEO

Two questions:

• Do you have SmartScreen's "Check apps and files" enabled on your machine?
• Is your machine domain/MDM joined (this may not matter, but if your organization is pushing down policies that change your internet zone settings it could be an issue).

[ShadowEO]

I did have Smartscreen enabled. As mentioned in my comment, my machine is not managed at all, no policies were defined.

However I have taken the Windows 11 Dev Insider Channel update and the issue seems to have been alleviated, I just attempted winget install git and a winget upgrade --all and things are working again. As with the previous commentors, while on that build, turning off Zone Identifier checks fixed the issue, but I no longer need the workaround now on 22000.65.