winget-cli
winget-cli copied to clipboard
microsoft
Provide mechanism to report SHA256 mismatch
Description of the new feature/enhancement
When a user encounters a SHA256 mismatch during install, the client should provide a mechanism to report the mismatch.
This would result in triggering the validation service to attempt to automatically correct the manifest. An Issue should be created to track this request in winget-pkgs and the URL to the Issue should be provided to the user. Once the issue has been corrected, the Issue should be closed.
If a duplicate report comes in for the same package and hash, the user should be provided the same Issue URL as the one originally created.
Edited based on feedback below.
https://github.com/microsoft/winget-pkgs/issues/10782 represents the work on the back-end services.
This could be implemented as a message to the user requesting authorization to report the issue. This could also be implemented in a setting so the user doesn't have to explicitly acknowledge the request, it would simply submit the request and reduce user interaction at every instance.
The default could either be auto-submit or request-permission.
Please add thumbs up 👍 for auto-submit (setting or argument to exclude submit). Please add thumbs down 👎 for manual request for prompt to submit (setting or argument to auto-submit) Note, this would only apply to the default winget community repository.
Additional work would be required to build a mechanism to submit something like this to the third party REST sources.
I suggest to ask for confirmation and give the user options to always submit, submit, don't submit, or never submit. For always/never submit, it would store the user preference in a setting and not ask again the next time.
Maybe this is obvious, but the client should be able to check somehow if there is already an open issue and not do anything (maybe return a message saying that "This package is broken; we're working on it!"). Opening a bunch of issues for Chrome not being up to date wouldn't solve anything. (Maybe it could put a thumbs up on the current issue somehow, although that would require the end user to authenticate with GitHub).
Good call out. I was thinking we'd provide the same "Issue" URL to the user if it's a duplicate report on the same hash failure. I should have stated that explicitly.
It look like wingetbot trying to update the hash mismatch but display version did not change because it blocked by Manifest-AppsAndFeaturesVersion-Error when the Azure Pipelines run. I saw some of the pull request get stalled or no-recent-activity. https://github.com/microsoft/winget-pkgs/pulls?q=is%3Apr+author%3Awingetbot+label%3AManifest-AppsAndFeaturesVersion-Error. Most of the pipelines failed with Display Version overlaps with another version while during wingetbot updating hash mismatch. Suppose wingetbot creates a new PR when package version and display version and display name change all together. If there is do not have display versions entries, change the PackageVersion have major entries and the display versions is differ from it which is the minor version only change the PackageVersion when major is greater than newer versions. If there is no major version set on PackageVersion entries like examples 6.03, App and Features Entries not be used due to it follow change PackageVersion to new PackageVersion: if the hash mismatch is come from the same link but different length and hash. Exculdes for github.com only.
Do we really need to be checking the hash if the package is digitally signed? Surely the signature will break if the EXE or MSI has been tampered with? Can we fall back on just validating the signature instead of the hash?
