Introduce a parameter for New-WtWingetPackage to ignore Hash mismatch

[mdurini-swisscom]

Hello, it will be nice to have a parameter to skip the hash mismatch error if we know that we can ignore it. Thank you in advance

[svrooij]

You have to convince me with a lot of valid arguments. I won't be accepting a PR on this without valid reasons.

Checking the hash with the one in the WinGet repository is to make sure that the installer is not changed somewhere in between. If WinTuner would allow skipping the hash you will put all the users in your tenant at risk.

The installer no longer matches the hash, this often happens if vendors re-use a single url for the installer and update the installer. WinGet considers this bad practice.

This is the only reason why there might be a mismatch, and the vendor (or package maintainer) should just fix the package in WinGet.

Do you have any good arguments to allow skipping the hash validation?

[mdurini-swisscom]

Hello, you got the point, for the package TrackerSoftware.PDF-XChangePRO the vendor re-uses the link for every new version. The link defined in winget is https://downloads.pdf-xchange.com/ProV10.x64.msi for the version 10.4.0.388, but actually the msi is related to the version 10.4.1.389. This is a bad practice, I know....I also tried to use the parameter "PackageScript" to be able to create a package and trigger winget client side, but winget is failing for the same reason....

[svrooij]

And if that happens, there seems to be an automated process that removes the installer.

Like:
microsoft/winget-pkgs@1df73e1

So if I understand correctly, the vendor is not providing a static URL for new versions, this is bad practice maybe you can ask them to fix it?

Checking the hash is a security feature, I'm really tempted to leave it in.

[mdurini-swisscom]

yes, correct, no static link...I understand your concerns, I will close this discussion and will manage this software in a different way. Thank you so much for your amazing work ;-)