CodeSector.TeraCopy - Would reverting to the homepage download link enable autoupdate?

[RavenMacDaddy]

Saw this being discussed a while back in #31547.

Judging by the latest redirect, it seems like the downloads are indeed being distributed in multiple/different channels, more specifically BackBlaze B2 and Digital Ocean Spaces.

More broadly speaking, would reverting to using to the homepage download link enable autoupdates for the app? For me personally, that's more important than redirects.

Pitch in and educate if something is missing.

[ItzLevvie]

I am fine with people using the non-versioned URL but someone must keep an eye on it for any sort of automatic updates as @wingetbot will not be always there to automatically update the Download URLs for you due to how large the WinGet package repository is. There are some packages that use the non-versioned URL which are completely skipped by @wingetbot so if you want those packages to be updated it will need manual updates by a human.

I think I remember seeing a comment posted somewhere in winget-cli or in this repository where a user stated that it would be a better user experience for everyone to be delivered an older version than for the user to experience constant InstallerSha256 errors with non-versioned URLs especially once you consider the current state of WinGet:

• where people are prevented from using --force in administrator mode. Some packages require running with administrator privileges but due to limitations in WinGet it does not allow you to bypass InstallerSha256 errors unless you are running WinGet without administrator privileges.
• where not everyone would like to use --force due to security issues, personal reasons, or company policies that are preventing them from using it.
• where not everyone has --force built-in to their automation workflows so non-versioned URLs can sometimes break people's workflows.

We cannot always make people happy because there is currently two situations here. If we decided to use:

• https://codesector.nyc3.cdn.digitaloceanspaces.com/teracopy3.9.2.exe which is the latest versioned URL as of 16th of July 2022 people will complain about WinGet delivering older version as soon as the developer has released a newer version such as TeraCopy 3.9.3 or TeraCopy 4.0.0.
• https://codesector.nyc3.cdn.digitaloceanspaces.com/teracopy.exe which is the latest non-versioned URL as of 16th of July 2022 people will complain about constant InstallerSha256 issues once the publisher rolls out a newer version of TeraCopy.

[RavenMacDaddy]

That does make sense.

How does the approach that Winget takes for hashes compare to something like Scoop?

I tried to find things on the subject, but so far haven't found anything substantial.

At least in terms of usability, hashes work out fine most of the time through autoupdates in the case of Scoop, but I guess it all boils down to your point about @wingetbot; it simply isn't fetching what's needed for it to work out at the moment.

[denelon]

@RavenMacDaddy

Some automation was built that could help some of these scenarios.

Daily scans detect hash mismatches, but sometimes that could still be almost a day with a bad hash. We have an Issue on the backlog to report these so we can hopefully reduce the time to restore:

• Provide mechanism to report SHA256 mismatch winget-cli#870

We have had an item on the backlog for quite some time related to heuristics to detect new versions. @vedantmgoyal2009 built a solution that is nearly identical to what we were thinking. I think the only things I'd modify are some of the names of the keys. We are planning on incorporating that directly into winget-pkgs so we can do a better job of detecting updates ourselves.

Our general preference is direct links to each version, but when they are not available, the best we can do is hash detection. The original Issue is:

• Auto generate manifests for newer versions #500

[vedantmgoyal9]

@denelon not sure if you're aware of and it's still possible like before to directly implement the automation into winget-pkgs repo. I thought the initial version of automation was kind of more inclined towards GitHub packages as well as since it was getting difficult to maintain separate ps1 scripts for every non-GitHub package. To make it easier to maintain, I have merged ps1 into the JSON, and have been using Invoke-Expression. BTW, the initial version of automation is still buried in git's commit history if we still need it 😉

I'm looking to extend support for non-GitHub packages for which we need to fetch multiple APIs to get update information.

[RavenMacDaddy]

Our general preference is direct links to each version, but when they are not available, the best we can do is hash detection. The original Issue is:

* [Auto generate manifests for newer versions #500](https://github.com/microsoft/winget-pkgs/issues/500)

Obviously for security reasons, right? Kind of self-explanatory; changed hash for the same version/build, something malicious could've changed.

I guess that's the challenge, isn't it? Either you get usability by just fetching a redirect to the newest version, or you manually point, which needs interest from users to solve leading to downtime, but at least you get a more reliable hash validation process.

Could security scans by your anti-malware intelligence and automatic version archive creation bridge that gap?

[vedantmgoyal9]

Obviously for security reasons, right? Kind of self-explanatory; changed hash for the same version/build, something malicious could've changed.

It's right, but we have azure pipelines to catch malicious/virus software. Additionally, every kind of update made to manifests, even metdata only changes, are also reviewed by community moderators manually, so there're very less chances that a malicious app can be added to the community repository.