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]

[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.