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…


Discover more from Out of Office Hours

Subscribe to get the latest posts sent to your email.

Leave a Reply

Trending