winget install hangs indefinitely with MotW Security Warning

[jantari]

Brief description of your issue

When winget-cli downloads an installer, it adds a MotW to it. If the source zone is not trusted, a GUI (!) warning popup shows when winget attempts to run the installer. This popup blocks the install forever and therefore breaks all unattended, automation and remoting scenarios.

Steps to reproduce

I am unsure why this doesn't reproduce with installers downloaded from the actual www internet (super-duper untrusted), but I can reproduce it reliably with an internal REST source + internally hosted installer files.

My REST source and installer files are hosted with rewinged on a routable domain (aka it looks like an internet website to Windows if it doesn't consider that it resolves to a RFC1918 IP? The domain wasn't explicitly added to the Intranet zone in inetcpl.cpl)

1. Set up an internal REST source, e.g. at whatever.company.com
2. Host installers for internal packages at whatever.company.com too
3. Ensure whatever.company.com isn't added to the trusted Intranet sites list in inetcpl.cpl / the registry
4. Issue a winget install --id something --source internal command to attempt a package installation
5. Observe how the MotW Security Warning pops up as a GUI window and the winget-cli process just hangs forever without an error, warning or timeout

Expected behavior

winget should either ignore/remove or not set the MotW on downloaded installers or it should check for it and abort the installation with an error so that the winget process ends instead of hanging and communicates an actionable error back to the user.

Honestly, since winget is constantly downloading installers from the internet in its default configuration, without issues, I don't see why a MotW should be applied or respected for REST / internal sources. My preferred method would just be to either not create it on download or remove/ignore it before invoking the installer.

Actual behavior

A MotW GUI (!) security warning pops up IF the user is in a scenario where a GUI is present (such as when logged in via RDP) and the winget process hangs indefinitely.

If the user is in a scenario where no GUI is present, such as when running as a service or connecting via ssh, there is no warning or popup or feedback of any kind and the winget install process just hangs indefinitely.

The following screenshot was captured in a GUI session via RDP to make the warning visible:

However please note that GUI access is rarely available in modern deployment scenarios and feedback on the CLI is mandatory.

Also, adding the domain the installers are downloaded from (e.g. whatever.company.com) to the trusted intranet sites list does "fix" the issue. But this is still a behavior difference vs the official winget community repository which never shows these warnings on install despite also downloading from the actual public internet.

Environment

WindowsPackageManager
MainCopyrightNotice

Windows: Windows.Server v10.0.17763.5206
SystemArchitecture

KeyDirectoriesHeader
----------------------------------------------------------------------------------------
Logs                 %TEMP%\WinGet\defaultState
UserSettings         %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json
PortableLinksUser    %LOCALAPPDATA%\Microsoft\WinGet\Links
PortableLinksMachine C:\Program Files\WinGet\Links
PortableRootUser     %LOCALAPPDATA%\Microsoft\WinGet\Packages
PortableRoot         C:\Program Files\WinGet\Packages
PortableRoot86       C:\Program Files (x86)\WinGet\Packages
InstallerDownloads   %USERPROFILE%\Downloads

Links
--------------------------------------------------------------------------------
PrivacyStatement         https://aka.ms/winget-privacy
LicenseAgreement         https://aka.ms/winget-license
ThirdPartSoftwareNotices https://aka.ms/winget-3rdPartyNotice
MainHomepage             https://aka.ms/winget
WindowsStoreTerms        https://www.microsoft.com/en-us/storedocs/terms-of-sale

AdminSettingHeader                        StateHeader
-------------------------------------------------------
LocalManifestFiles                        StateDisabled
BypassCertificatePinningForMicrosoftStore StateDisabled
InstallerHashOverride                     StateDisabled
LocalArchiveMalwareScanOverride           StateDisabled

[denelon]

@jantari, WinGet isn't the source of the mark. For the community repository, the zone is changed after the installer has been downloaded and verified against the SHA256.

We will have to look at a mechanism like an administrator setting, or a GPO (Group Policy Object) setting to apply the same behavior to non-default sources.

If the installer URL is coming from a trusted zone, then the security warning shouldn't appear.

[jantari]

Thanks for clarifying. I do believe non-default sources should get the same behavior.

[vedantmgoyal9]

@jantari I have found a fix, but you will have to sacrifice "security".

You can execute these PowerShell statements, to tell Windows to not mark file attachments with their zone information.

New-Item -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments'
New-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments' -Name 'SaveZoneInformation' -Type DWord -Value 1

https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.AttachmentManager::AM_MarkZoneOnSavedAtttachments

[jantari]

@vedantmgoyal2009 I am currently using a better (less inseure) workaround, programmatically ensuring the winget REST repository is in the trusted intranet zone:

[string]$YourSourceURL = 'https://source.company.internal/api'

[System.Uri]$ParsedSourceUri = $null
[bool]$ArgIsValidAbsoluteUri = [System.Uri]::TryCreate($YourSourceURL, [System.UriKind]::Absolute, [ref]$ParsedSourceUri)
if ($ArgIsValidAbsoluteUri) {
  reg.exe add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\$($ParsedSourceUri.Host)" /v http /t REG_DWORD /d 1 /f
  reg.exe add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\$($ParsedSourceUri.Host)" /v https /t REG_DWORD /d 1 /f
} else {
  throw "winget source URL is invalid"
}

[denelon]

@jantari I believe this issue has been fixed. The key is marking the repository as "trusted" when adding the source to WinGet. That way when the installer hash has been verified, the MotW will get modified, and the security warning shouldn't be present.