You may or may not have seen a blog post from Thomas Mahony talking about how Winget is drowning and one person is keeping it afloat:
It occurred to me at the time that would mean a backlog of new apps being added. What didn’t occur to me: the backlog would also include app version updates, and that could easily cause failures when trying to use Winget when provisioning a device.
Let’s look at an example from the https://github.com/microsoft/winget-pkgs repository where all this stuff happens. There are multiple pull requests opened to update Chrome: two different ones that detected the new version and created a PR automatically, and one that detected that installations were failing because the current Winget entry refers to an installer (.msi file) that no longer matches the hash (because it’s a newer version):

And three PRs are stalled, for various reasons, so someone will need to intervene. Fine, but if you are actually trying to install Chrome using Winget, you might see a failure that looks like this:

If you were doing an interactive install, you could override this:
winget settings --enable InstallerHashOverride
winget install -e Google.Chrome --ignore-security-hash
But if you try to do that when running elevated (including LocalSystem, which would be used by management and provisioning tools), it will be blocked:

So all you can really do is ignore the error and continue anyway. At least until an overloaded person intervenes…






Leave a Reply