REST source configured via Group Policy: downloaded installers get Mark of the Web (ZoneId=3)

[dev-fYnn]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget install

Brief description of your issue

When installing/updating software via winget from a REST source that was added through Group Policy, downloaded installer files (e.g. MSI) are marked with the "Mark of the Web" (Zone.Identifier, ZoneId=3). This causes Windows to show the "Open File - Security Warning" dialog when the installer is executed, even though the source was explicitly trusted and configured via Group Policy.
This leads to never ending loops in the installation process. The process worked without conflicts until Version 1.29.

Steps to reproduce

1. Add a winget REST source via Group Policy (EnableAdditionalSources / configured source policy).
2. Trigger an installation, e.g.:

Expected behavior

Since the source was explicitly added and trusted via Group Policy, installers downloaded through winget from that source should not be flagged with Mark of the Web / ZoneId=3, or the resulting security prompt should not block/interrupt unattended or scripted installations initiated by winget.

Actual behavior

Downloaded installer files consistently carry ZoneId=3 in their Zone.Identifier alternate data stream, causing the standard "Security Warning" dialog to appear when the file is executed — even outside of winget (e.g. manual double-click), and this cannot be suppressed via the SaveZoneInformation policy:

Environment

- Winget version: 1.29.280
- Windows version/build: 25H2 Build: 26200.8655
- Source type: private REST source (Winget-Repo), added via Group Policy
- Installer example: Google.Chrome (MSI)

[seanmcguire-aag]

We are seeing the same thing. We use zipped installer packages and when the files are extracted by winget they are marked with Zone 3

The site the packages are downloaded from are added to the trusted sites zone via registry entry

As with @dev-fYnn, this was working until the latest release.

[seanmcguire-aag]

As per #4046 our repo was added without the trust level of 'trusted' - readding the repo with this flag resolves the issue, although having the site added to the trusted sites zone has worked until the latest version, so interested to know the background of this?

[Trenly]

@dev-fYnn and @seanmcguire-aag - would either or both of you be able to share the way you have configured your additional sources though policy (redacting source URLs) ? I'd like to fully understand your configuration here.

[dev-fYnn]

@Trenly and @seanmcguire-aag, we added the source through Group Policy in our company environment.

We configured the source using the first policy and the following JSON string:

{
  "Arg": "https://{URL}/api/",
  "Data": "",
  "Explicit": false,
  "Identifier": "Winget-Repo",
  "Name": "Winget-Repo",
  "Type": "Microsoft.Rest"
}

It worked until last update perfectly.

[Trenly]

Thanks @dev-fYnn!

There was a behavior change between  v1.28.240  and  v1.29.280  which comes from 5c46ba19 - Improve MOTW error handling in download flow (#6127). It changed DownloadFlow from:

 VerifyInstallerHash -> UpdateInstallerFileMotwIfApplicable -> RenameDownloadedInstaller

to:

 VerifyInstallerHash -> RenameDownloadedInstaller -> UpdateInstallerFileMotwIfApplicable

That reordering makes AES/MOTW operate on the final installer filename (with extension), which changes MOTW behavior in practice. I also confirmed the Group Policy trust-level parsing/default path itself is unchanged across those tags. While this shouldn't actually “break" the Group Policy, it likely exposed a latent trust configuration gap.

Since #6127 moved MOTW/AES processing to run after rename, AES now evaluates the real installer filename (with extension) instead of the old temporary hash filename (extensionless). That matters because AES/Attachment Manager behavior is file-type sensitive; the old flow could produce inconsistent outcomes that sometimes looked like MOTW was effectively cleared. Importantly, it also produced inconsistent outcomes where the MOTW was not cleared when it should have been.

For Group Policy sources, trust logic is unchanged: if  AdditionalSources doesn’t explicitly include  TrustLevel: ["Trusted"] , winget treats it as  None , and the non-trusted path keeps/applies Internet MOTW ( ZoneId=3 ). In older builds, bugs/ordering in MOTW handling could mask that and make it appear to work. After  5c46ba19 , behavior became more deterministic, so untrusted policy sources consistently retain MOTW.

---

Could I ask you to try:

{
  "Arg": "https://{URL}/api/",
  "Data": "",
  "Explicit": false,
  "Identifier": "Winget-Repo",
  "Name": "Winget-Repo",
  "Type": "Microsoft.Rest",
  "TrustLevel": ["Trusted"]
}

[dev-fYnn]

@Trenly It seems to be working with the TrustLevel, but I will only be able to test it fully on Monday.
Thank you for your help. I will let you know whether it worked.

P.S. Is the TrustLevel included in the WinGet configuration export command? That is where I got the JSON string from.

[Trenly]

@Trenly It seems to be working with the TrustLevel, but I will only be able to test it fully on Monday. Thank you for your help. I will let you know whether it worked.

P.S. Is the TrustLevel included in the WinGet configuration export command? That is where I got the JSON string from.

It should be. In winget configure export , source units include:

settings:
  trustLevel: trusted

But, only if  SourceTrustLevel::Trusted  is set. If a source is untrusted ( None ),  trustLevel  is omitted from the export rather than emitted as  none .

[dev-fYnn]

@Trenly i can now confirm, that this flag fixed the issue. Thanks.