Winget-cli: Abort on hash verification failure

[jasperweiss]

Currently, when winget fails to validate the hash the user is asked whether to continue or not.
If the installer's hash does not match the one in the manifest there's a serious problem and the process should abort immediately without asking the user. There's no legitimate reason for a binary suddenly being different from the one listed in the manifest.

[retnikt]

With, for example, the Amazon Web Services CLI, there are no version-pinned URLs available AFAIK, so the URL to the latest version must be used. In cases like this, a hash mismatch merely indicates there has been an update to the AWS CLI that has not yet been accounted for in the manifest in the repo.

[jasperweiss]

That itself is a problem. Just asking the user to blindly trust the binary in those cases is NOT a solution.
Manifests should link to a specific binary that is not supposed to change, if that isn't possible it shouldn't mention a specific version number and hash to check against but rather verify the publisher's signature.

In cases like this, a hash mismatch merely indicates there has been an update to the AWS CLI that has not yet been accounted for in the manifest in the repo.

How is the user supposed to know that? If the user is just expected to think that a hash mismatch indicates a legitimate update to the binary, it leaves everyone susceptible to the exact attack that a verification is supposed to protect against.

[jasperweiss]

@retnikt I realize I might have come across a bit harsh there, which I didn't mean to. It's just that this seems like a very bad design decision to me and it would be regrettable if it were ever exploited at some point.