Browsers test or canary versions have always hash problem

Description of the new feature / enhancement

We know that package managers, such as winget and chocolatey, have a problem when a user tries to install beta or canary versions of web browsers through them. This is due to the security feature of package managers, where it compares hash numbers. However, the problem is that the latest experimental versions of browsers updates so often that their hash doesn’t seem to ever update in time, and thus the installation cannot be performed.

Could it be possible that certain parties, such as the test versions of major browsers, could be whitelisted from this check? I understand that this idea may be shot down simply because winget would be filled with requests to get some application whitelisted. However, this feature does not need to be open, i.e., only a few parties would get this right by default, such as Edge canary, Chrome canary, Firefox nightly, Brave, Vivaldi, and Opera. So initially, this would only be possible for these largest ones by default.

Fewer people even install Canary versions, so this whitelisting would probably not be as big a problem as many people initially imagine it to be.

Any thoughts?

Proposed technical implementation details

"Installer hash does not match; this cannot be overridden when running as admin"

Perhaps it can just install the thing :)

The issue names no files, tests, or entry points. Start by locating the CLI's installer hash-verification path and reviewing how browser test or canary packages are represented; the work would need an agreed whitelist policy and clear rules for when an installation may bypass the existing check.