Use of installer hashes causes frequent errors. Instead, rely on signatures in binary.

[MarcoPeraza]

Winget relies on hashes instead of signatures. Installers are updated before the winget package is updated, leading to failed installs

If you try to install Google Chrome or Spotify right now, for example, you will get an error: "Installer hash does not match; this cannot be overridden when running as admin"

Windows has had extensive support for signed executables for many many years. Yet winget is still using hashes of installer executables.

One of two things must happen for these errors not to occur:

1. Winget prohibits using non-version-specific ('latest') URLs in manifests. The current behavior otherwise stays the same.
2. Winget allows pointing at a 'latest' URL. It verifies the signature, not the hash, of the downloaded file. Some work will be required w/r/t concept of a "version" in winget. Such a package would not represent a particular version of a program, but the way to install the latest version of a program..

Steps to reproduce

Install any package that has a non-versions-specific download URL and that has been updated without a corresponding update in the winget manifest. As of time of filing this bug, Google Chrome and Spotify both have this bug.

Expected behavior

Winget downloads the executables, sees it is signed by the appropriate publisher, and installs it anyway.

Actual behavior

Winget fails to install the package

[denelon]

We've been working on some back end improvements to capture when installers change at the given URL. This has already reduced the time between a package update and an automated PR to fix issues like these. Not all installers are versioned, so we've been discussing the implications of allowing the concept of "latest" as a sentinel value for installers that aren't versioned.

The installer for "Google.Chrome" reports a different version than what we see in add/remove programs with list. We've still got more work to do until publishers can help close the gaps.

[MarcoPeraza]

Yesterday I tried to set up a new machine with my set up script that installs a few pieces of software through winget. And I ran into not one but two hash mismatch errors: Foxit.PhantomPDF and Spotify.Spotify.

The Foxit PhantomPDF manifest lists the following URL https://www.foxitsoftware.com/downloads/latest.php?product=Foxit-PhantomPDF-Standard&platform=Windows&package_type=exe&language=L10N .

Unless Foxit commits to update the winget manifest itself before releasing a new version, the current approach will always produce hash mismatches for some amount of time because that URL will always get the latest Foxit package but you are hard coding the hash of a particular version.

This makes using winget in scripting scenarios unreliable.

[denelon]

@MarcoPeraza if the publisher doesn't provide a URL per version of the package, there will be hash mismatches that must be detected and resolved. Ideally, publishers will provide a stable URL per version of their software. We are looking at solutions to reduce the amount of time an invalid hash is present, but it is a reality we must deal with in some cases with some software packages.

Not all software is signed either. That has also been a problem raised by many smaller ISVs and open-source authors. I don't expect to find a one-size fits all solution here. Hopefully, over time, this will become less of a problem than it is today.

[MarcoPeraza]

@denelon thank you for your response. I understand that there is a bigger picture here, involving upgrading packages, that might require the current approach of manifests describing particular package versions, not just the way to install the 'latest' version.

I wonder if the two approaches can exist in parallel. Some packages could be versioned and supported by winget's package upgrade. But others, such as for software that has built-in autoupdate, are just described by a manifest that points to the 'latest' version and rely (ideally) on code-signing (or as a last resort, where software developers do not adopt code-signing, Microsoft fixing the hashes).

[denelon]

Yes, that's why I kept this as a feature. I think we're going to have several different approaches, for how we identify and trust various packages. When we get a bit further in the discussion, I may change the title or ask you to change the title of the issue. I think we're going to need a few more "and" features rather than "or" features. Thank you for submitting the issue 👍

[MarcoPeraza]

Hi, today I tried to install Chrome using winget and again ran into this same error.

winget is unreliable for installing one of the most commonly installed Windows apps in the world.

[MarcoPeraza]

Given the state of the Chrome package, should winget even offer the package? Wouldn't it be better to not have the package at all than to frequently error out as it does now?

[Andrej730]

That's a nice feature with those "latest type" urls. Otherwise hash won't match between two users .some developers tend to add some additional info at the end of exe file - like Jvup=1&browser=YandexBrowser/32/17.1.0.2034&scup=1&download_date=1677434515 to indicate the way the executable was downloaded but file signature stays the same.

But I guess it would also take changes to schema

[NJT145]

I have the same issue on package "PsiphonInc.Psiphon". I updated its hash, but before my pull request approved, its hash changed again. Any way to automate this?

[yamgarcia]

Same problem with Microsoft.PowerAutomateDesktop. It's hard to believe Microsoft would let the one first-party package manager unusable like this.

[Turmaxx]

I have the same issue with Google.PlayGames.Beta Hopefully they move to signatures or something.

[Tone866]

This should really have a higher priority. Winget is really cool, but with this bug/implementation half of the apps aren't upgradable. Sad that it's open since two years.

Force also isn't good option. What if the hash is really wrong, the file is manipulated and you still install it? not good..

[uffemcev]

An attempt to automation without interactive popups. These commands must be run as an administrator. Winget v1.6.2771.

$id = "Google.Chrome"
winget settings --enable InstallerHashOverride
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v "LowRiskFileTypes" /t REG_SZ /d ".exe;.msi;.zip;" /f
runas /trustlevel:0x20000 /machine:amd64 "winget install --id=$id --accept-package-agreements --accept-source-agreements --ignore-security-hash --exact --silent"

[jason-nyc]

Same with winget install --id=JAMSoftware.TreeSize.Free -e. I knew there was a reason to stick with choco

[elisimpson]

Following as this is still a major issue and isn't getting attention. If it's not going to be resolved manifests with "latest"-type URLs should be purged from the database and no new ones should be allowed.