[Feature Request]: Enhance AllowList/GPO mode with native Version and Optional Hash Pinning

[dotBATmanNO]

The request

First of all, thank you for a great project.

We are currently evaluating Winget-AutoUpdate (WAU) in an enterprise environment and have been impressed by the existing AllowList model and GPO integration.

While reviewing the project, we noticed that version pinning has already been explored through the mod framework (#1126). This feature request is therefore not intended to replace existing mod capabilities, but to propose a native policy-driven implementation for enterprise deployments.

Current behaviour

AllowList entries are application-centric:

7zip.7zip

Result:

• Application is approved
• Latest version from the configured Winget source may be installed

This provides application approval but not version approval.

Enterprise use case

Many organizations need to distinguish between:

• Application approval
• Version approval
• Package integrity approval

Typical deployment model:

Pilot
↓
Version approval
↓
Production rollout

Administrators may want to approve:

• A specific version
• A specific package hash
• Both version and hash

Proposed syntax

Current:

7zip.7zip

Possible enhancements:

7zip.7zip@26.02

or

7zip.7zip@26.02#SHA256

Expected behaviour

7zip.7zip
→ Current behaviour

7zip.7zip@26.02
→ Only install/update when version 26.02 is available

7zip.7zip@26.02#SHA256
→ Only install/update when both version and hash match

Benefits

1. Builds on existing version pinning concepts

WAU already appears to have work related to version pinning through mods.
Native policy support would make the capability easier to consume at scale through GPO and centralized administration.

2. Staged rollout support

Allows administrators to approve versions after pilot validation.

3. Supply chain governance

Provides stronger controls when managing trusted software repositories and external package sources.

4. Auditability

Makes it possible to document:

• Approved application
• Approved version
• Approved package hash

5. Regulated environments

Useful for organizations operating under regulated change-management and software governance requirements.

Alternative implementation

The exact syntax is less important than the capability itself.

A structured configuration model, JSON configuration, registry policy, or additional GPO settings would all be acceptable as long as version/hash approval can be managed centrally.

Thank you for considering the suggestion.

Is your feature request related to a problem?

AU AllowList currently allows approval of applications but not specific versions or hashes.

As software supply chain attacks increasingly target trusted repositories, release pipelines and maintainers, some organizations may wish to retain automated updates while maintaining explicit approval of versions and, optionally, package hashes.

This would support pilot deployments, staged rollouts and audit requirements without changing the current simple AllowList workflow.

Additional information

No response

[dotBATmanNO]

Disclaimer

Feature request drafted with AI assistance,
challenged by a security engineer,
validated through an actual enterprise pilot,
and submitted by a human who will be accountable for the consequences.

[KnifMelti]

but to propose a native policy-driven implementation for enterprise deployments.

This would be really useful!