Not sure what you mean. The publisher of the app in the Winget repo is responsible for delivering both the software and the manifest, I’m not referring to the hash of Winget itself. It’s the responsibility of the software publisher to provide a correct and up to date manifest along with the actual installer. If the installer cannot be verified, it has no business being on a software repository that is used by IT administrators. We might as well go back to manually taking care of installers and ignoring Winget entirely.

I’d fire an admin on the spot if I saw them pushing ‘winget upgrade --all --force’ on thousands of computers if --force would bypass verification checks.

I don’t agree, and I think you are using an extreme case as an example that we are not talking about. No one with a healthy brain would do widget upgrade --all --force, and every example in this thread was about one concrete app installation/upgrade.

The override is useful when some concrete app upgrade fails (during winget upgrade --all for example) because the package contains an invalid hash.

In the world of all packages being updated, this would not be necessary, and I would agree that the package author should provide a proper hash. But the reality of the winget package repository is that many packages are outdated. And because many apps do not use versioned installer file names (i.e. URL stays the same when a new app version is published), the hash gets outdated because the executable stated in the manifest was updated in the remote location by the app developer while the corresponding package was not. Many packages are “maintained” by volunteers, not the app developers directly.

You might NEED to install the new app version, maybe because the new app version contains important security updates, important bug fixes, or whatever.

In that case, you want to tell Winget, “Hey, I know what I’m doing, and I’m ok with the risks involved,” because the risk associated with using the old app version may be bigger for you. In that case, winget trying to be “secure” is not actually secure.

In that case, you are screwed. And what will you do in such a situation? You will probably go to the app homepage, download the installer ANYWAY, and install it manually if you evaluate the risks involved. So the result is the same.

chocolatey has a simple solution to this - it lets you provide your own hash via --checksum64 or simply ignore the hash via --ignore-checksums - simple, effective, and useful. I think it’s actually more secure because by using --checksum64, you can easily use a valid hash provided by the app homepage, so the installation of the new version is secure. When Winget does not provide that option, the user might ignore the checksum validation completely and install it right away, fingers crossed.

I think this is the classic example of an application trying to protect users from themselves, which, in the case of an application for administrators, does not make sense and is only annoying and can backfire when it does not provide a workaround.

I don’t think you need to have that concern. There are any number of things that if you copy and paste into a administrator command prompt will absolutely trash/compromise/etc. your computer. An admin command prompt can do anything on a Windows machine (even perform an escalation to SYSTEM). So I don’t see a point in being concerned about it in this one small case. Especially if someone has turned off UAC.

Almost 3 years later and this is still an issue, how has this not been fixed yet Microsoft.

winget install --silent --accept-package-agreements --accept-source-agreements --force --disable-interactivity --exact Asana.Asana
Found Asana [Asana.Asana] Version 1.15.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://desktop-downloads.asana.com/win32_x64/prod/latest/AsanaSetup.exe
  ██████████████████████████████  98.1 MB / 98.1 MB
Installer hash does not match; this cannot be overridden when running as admin

As companies point more and more to a /latest.msi /latest.exe this will end up becoming an issue for all applications.

Hi, is there any reason why this feature is disabled at all for users running as admin? This seems to be upside-down. Usually, running as administrator gives you more privileges, not less.

I also just want to reiterate that when you turn UAC off on a machine, it’s impossible to not run as admin, so the hash override feature becomes completely unavailable.

We’ve been discussing the behavior for the hash override behavior. “–force” doesn’t really convey that you are taking a risk in installing a package when the hash doesn’t match. I think we’re leaning towards an administrative setting to enable the hash override. Then we will need to enable this mechanism to work both for user and admin modes as some programs don’t work when installing under one or the other mode. We will also need to put out a very clear warning about the fact that the hash was ignored.

We now have a Group Policy to determine if the ability to override hash validation is available to users. We are discussing adding a setting to the “settings.json” file to “enable the ability to --force”. Once that is in place we can allow either a user or an administrator to override the hash validation.

I’m converting this bug into a feature to capture the work.

Ooooh I love that chocolatey feature of being able to provide a checksum.

On Mon, Jan 15, 2024, 13:07 Pavel Trka @.***> wrote:

Not sure what you mean. The publisher of the app in the Winget repo is responsible for delivering both the software and the manifest, I’m not referring to the hash of Winget itself. It’s the responsibility of the software publisher to provide a correct and up to date manifest along with the actual installer. If the installer cannot be verified, it has no business being on a software repository that is used by IT administrators. We might as well go back to manually taking care of installers and ignoring Winget entirely.

I’d fire an admin on the spot if I saw them pushing ‘winget upgrade --all –force’ on thousands of computers if --force would bypass verification checks.

I don’t agree, and I think you are using an extreme case as an example that we are not talking about. No one with a healthy brain would do widget upgrade --all --force, and every example in this thread was about one concrete app installation/upgrade.

The override is useful when some concrete app upgrade fails (during winget upgrade --all for example) because the package contains an invalid hash.

In the world of all packages being updated, this would not be necessary, and I would agree that the package author should provide a proper hash. But the reality of the winget package repository is that many packages are outdated. And because many apps do not use versioned installer file names (i.e. URL stays the same when a new app version is published), the hash gets outdated because the executable stated in the manifest was updated in the remote location by the app developer while the corresponding package was not. Many packages are “maintained” by volunteers, not the app developers directly.

You might NEED to install the new app version, maybe because the new app version contains important security updates, important bug fixes, or whatever.

In that case, you want to tell Winget, “Hey, I know what I’m doing, and I’m ok with the risks involved,” because the risk associated with using the old app version may be bigger for you. In that case, winget trying to be “secure” is not actually secure.

In that case, you are screwed. And what will you do in such a situation? You will probably go to the app homepage, download the installer ANYWAY, and install it manually if you evaluate the risks involved. So the result is the same.

chocolatey has a simple solution to this - it lets you provide your own hash via --checksum64 or simply ignore the hash via --ignore-checksums - simple, effective, and useful. I think it’s actually more secure because by using --checksum64, you can easily use a valid hash provided by the app homepage, so the installation of the new version is secure. When Winget does not provide that option, the user might ignore the checksum validation completely and install it right away, fingers crossed.

I think this is the classic example of an application trying to protect users from themselves, which, in the case of an application for administrators, does not make sense and is only annoying and can backfire when it does not provide a workaround.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/winget-cli/issues/715#issuecomment-1892045321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP5N2PZAPMGMYVGZ5OTCHW3YOULYHAVCNFSM4WP7F3A2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGIYDINJTGIYQ . You are receiving this because you were mentioned.Message ID: @.***>

In that case it’s an even better thing that --force doesn’t let you skip the hash validation. If Winget is supposed to be the end all be all package management solution, validation is key. If not, it will be stuck in hobbyist land forever. My point stands, whoever maintains the manifest needs to supply a valid hash. It’s trivial to do (curl package, get-filehash).

Found this issue today, our company installer portal has a few applications which now do not install -

Example: winget install TeamViewer.TeamViewer --force Installer hash does not match; this cannot be overridden when running as admin

We seriously need a --BypassHashCheck asap, or allow --force to bypass, as at that point the user accepts responsibility.

I see the point regarding verification of binaries. But Microsoft has a very good code signing system baked into Windows that winget could leverage to provide those same guarantees.

Maybe another way of putting it: what attack are you protecting against? Someone taking control of the software vendor’s download URL and replacing it with malicious software? In that situation, users are screwed anyway. 1) auto-update mechanisms in the software are likely compromised too and 2) the user’s likely recourse after winget failing is to go to the vendor’s website… and download that same binary, and 3) they would also need to have compromised the code signing certificate. Like Raymond Chen says, “it rather involved being on the other side of this airtight hatchway”.

We’re looking at several options to deal with this scenario. There have been several concerns about having command-line overrides that could potentially result in malicious code getting installed by the Windows Package Manager (eg. copy-paste this command from some “bad actor”).

A few options have been suggested:

Have a setting requirement to enable the capability (enables a Group Policy to block behavior by IT administrators). Change the value to something other than --force (something more akin to --IgnoreSecuritysha256).

Generally, it is preferred not to ignore security checks. Are there any other suggestions here?

Yes, when I use --force I get the following error still: “Installer hash does not match; this cannot be overridden when running as admin”

Note that when using an admin account and running Windows with EnableLua=0, all applications run with full privileges. This turns UAC off. It would be nice if the hash override would remain available to users running with this configuration. Fwiw, I have never encountered a feature in any Microsoft product that did not work with this configuration, except as a bug.

Did you run it with --force?

This becomes an annoying problem when utilizing ssh on Windows. When you ssh into another Windows machine you’re connecting as an admin. In this situation it is required that you install an application via cli, and if that application’s installer hash doesn’t match you’re simply out of luck.

I’m not sure I understand why there isn’t just an additional flag you can provide. If the team feels that --force isn’t descriptive enough; just create a new flag… As per @dennish78’s concerns, you could limit this option to modifying one application at a time.

A grand majority of the programs in winget’s catalog were not and are not moderated by the developer of the program itself…

Of course the real solution is to force the hash to be part of the manifest. Why would a hash be non-mandatory? It’s trivial to add.

That is the typical answer of a theorist. Who should customize the hash for WinGet? Google?

If an administrator (practitioner), trust Google, then a download link to the latest available version is enough for. How should the administrator adjust the hash in the WinGet if the binary is changed (by Google!)?

The --force parameter must allow an administrator to force an installation. What else is the purpose of --force?

Not sure what you mean. The publisher of the app in the Winget repo is responsible for delivering both the software and the manifest, I’m not referring to the hash of Winget itself. It’s the responsibility of the software publisher to provide a correct and up to date manifest along with the actual installer. If the installer cannot be verified, it has no business being on a software repository that is used by IT administrators. We might as well go back to manually taking care of installers and ignoring Winget entirely.

I’d fire an admin on the spot if I saw them pushing ‘winget upgrade --all --force’ on thousands of computers if --force would bypass verification checks.

Of course the real solution is to force the hash to be part of the manifest. Why would a hash be non-mandatory? It’s trivial to add.

I’ve found the issue is usually the manifest pointing to a “latest” or unversioned download link. These change frequently and of course the hash won’t match with every change. Maybe we should disallow pointing to unversioned installers in the manifest, or have a special flag that allows “latest” installs without a hash.

@Skeb1ns I am Using the great tool “WingetAutoUpdate” in my company, which lets you set a “Blacklist” for auto updates. For me in the blacklist are Chrome, Teamviewer and Office apps. Maybe that helps you.

To deploy winget apps I am using winget-install which works fine for me with Intune

WinGet operates in several differnt kinds of environments. This issue is really about how we initially implemented the hash override mechanism. We agree it needs to change, but it’s considered a breaking change which would require a “major” version bump.

This is actually the current top reason we would consider that activity. We’re compiling a list of other potential reasons to justify a major version bump. It’s not something we take lightly, and we also want to be very explicit about other changes being considered:

• https://github.com/microsoft/winget-cli/issues/2128