[New Feature]: Manifest Verification Tiers

✅ (Update 5/14/26 - See new addendum at the bottom with a simpler, easier-to-develop, and likely more practical initial implementation)

---

Description of the new feature/enhancement

I had an idea for an additional security layer that would be like a mid-way verification strategy compared to something like #100 . But it would also sort of build on that as I'll describe below. And to be clear, this would be in addition to the existing checks and procedures.

Idea (First Half):

For the first part of the feature, I'm basically imagining there be a database containing known-good properties about the publisher and/or their software products, which could be used to 'verify' a specific manifest to varying degrees. Then there could be a kind of flag or attribute that would indicate the manifest as "verified".

Idea (Second Half):

Then for the other part of the feature, there would be the added ability for a user to limit their WinGet CLI to only considering packages with a specific verification level. And I imagine this 'verification' tag would be an additional column in the WinGet CLI, but the user could also choose to filter and only show verified packages if desired.

More specifically, I'm imagining there be a database/ list of known public keys for publishers that sign their installers, as well as a list of associated known domains (or even specific URL paths) at which those companies host their installers.

Use Case:

I think the use case would be in situations where the publisher doesn't maintain their own WinGet packages. This way, users could know exactly to what level the packages they are installing were verified. Yes each package is checked by moderators, but at the same time I think users would appreciate knowing if a package has had a specific type of verification check, and exactly in what way.

Proposed technical implementation details (optional)

Implementation Ideas

As an example, the structure of a single publisher entry in the database might look something like this:

• Publisher: master/manifests/m/Mozilla
    ↳ Publisher Managed Package:
        ↳ False
    ↳ Known Signing Keys:
        ↳ [30 82 02 0a 02 82 02 01 00 c9 52 d8 96 ... ]
    ↳ Packages:
        ↳ Firefox
            ↳ Known Installer Host URLs:
                ↳ https://download-installer.cdn.mozilla.net/pub/firefox/releases/*
        ↳ Thunderbird
            ↳ Known Installer Host URLs:
                ↳ https://download-installer.cdn.mozilla.net/pub/thunderbird/releases/*

As part of the automatic scan for submitted PRs, the bot could run a check for:

1. A signature on the installer file itself (which I imagine already happens at some point of the dynamic analysis anyway), and if so, compare it to the known one.
2. If there is no signature or it's self-signed, compare it to the known URLs it should be hosted on for that package.

Then from there, I figure there are two options for how to approach classifying that individual manifest:

• A single verified tag if either passes
• Have separate tags for each test.

In the case where each test yields its own tag, then there would be the matter of deciding what passed tests would be required to consider it 'verified' by default:

• Verified Signature
• Verified URL
• Both

The verification tiers might look something like this, from highest to lowest strictness:

1. Package managed by original publisher
2. Both Verified Signature and URL Required
3. Verified Signature Required
4. Either Verified URL or Verified Signature Required
5. Standard checks only (like currently), no additional verification required

Then if the user wanted to set their own level they considered 'verified', they could change it from whatever the default is. There could even be an option to let the user choose any combination of tags.

---

And of course, there could be a policy for what to do with unverified manifests. Perhaps for very popular software by big companies that one would expect to always sign their software, you could have a special requirement for a certain verification level for the manifest to be allowed into the repo at all, even if it would otherwise pass normal checks. But for the rest of the repo in general, it would just be like it currently is with the existing checks on the submitted manifests, and on top of that software verification information would be added over time.

---

Addendum: An Initial "Stepping Stone" Implementation - Locally Curated Trust Lists

Perhaps a more practical way to initially implement, is instead of the trusted list of keys and urls being determined centrally for all users by Microsoft, each individual would manually add the rules for some or all of the apps they want to on their own system.

Then once the feature is physically in place, Microsoft could decide if they want to deal with creating their own curated online database of manual verification available for everyone. So it would sort of reminiscent to AppLocker or WDAC where companies manually define policies for allowed apps, but at the winget level for certificate and download url. Then of course there could be optional modes for whether to use the central repo list, or only the local list, or a combination. I actually think companies would prefer this solution anyway.

Main benefit to this: No additional maintenance work required by Microsoft after adding the feature, because it's handled at the user level.

---

Other related:

• https://github.com/microsoft/winget-cli/discussions/4012

Start by reading the related winget-cli discussion #4012 and compare its proposals with this issue's local trust-list addendum. Progress requires an agreed initial scope and acceptance criteria for trust rules, verification levels, and CLI filtering; the issue does not name implementation files or tests.