Upgrade delay setting for 'winget upgrade --all'

[mdevolde]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

Add an optional user setting installBehavior.upgradeDelayInDays that delays upgrades when running winget upgrade --all by skipping updates whose ReleaseDate is newer than the configured age, reducing exposure to newly published (and so, supply-chain/bug risky) releases.
So, for exemple, if installBehavior.upgradeDelayInDays is set to 5 days, and a new version of Mozilla.Thunderbird was released just yesterday, when running winget upgrade --all, the installation of this upgrade will be delayed until in 4 days.

It is the same idea as this config param from dependabot: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-

Proposed technical implementation details

Read installBehavior.upgradeDelayInDays from settings (default: 0).
During winget upgrade --all, for each available upgrade, if installBehavior.upgradeDelayInDays > 0, compare "today" to the package's ReleaseDate (prefer the selected applicable installer’s ReleaseDate, fallback to manifest.DefaultInstallerInfo.ReleaseDate).
If the age is less than the configured delay, skip that upgrade, continue processing the rest, and show a summary indicating how many upgrades were skipped due to the delay (with guidance to upgrade individually to override).
If ReleaseDate is missing/invalid, skip that upgrade in the same way as above.
If the age is more than the configured delay, process that upgrade in a classical way.

Those verifications are located in UpdateAllApplicable, so upgrading a single package is'nt affected by them.

[JohnMcPMS]

If the feature is dependent on attacker suppliable information (manifest contents), it seems to be largely avoidable. There is certainly the scenario where the ISV is compromised, but the release date information in the manifest is supplied correctly. In addition, we don't have CVE type information, so the upgrade you are delaying could actually be fixing something important in the version that you have.

I don't have a problem with the feature generally, I just don't want to position it as a security barrier.

In terms of having an always present piece of information, at least from winget-pkgs, the original commit date for a version could be used (so not affected by any future updates for that version).

[mdevolde]

JohnMcPMS I agree with you on these points.

I’ll update my PR to use the commit date instead of the manifest date, which will indeed provide more reliable information.

As for the fact that the update could effectively be a fix for a CVE, that’s also true, but I don’t think there is a solution about that. Since the user can set the number of days (for the delay) and can bypass it by upgrading by package, I don’t think it’s a blocking issue (but you are the one to decide :), if you have an idea about that, I'm open mind !)

[ehoogeveen-medweb]

The way the minimum release age works (at least conceptually) in tools like npm is that it queries all versions of each package and then filters out any versions that were published too recently. So rather than being explicitly delayed, it's as though they don't exist yet, and they'll naturally appear as time passes.

I don't know how winget works, but if it also gets a list of all published versions (with associated commit dates) then I think it would make sense to make it work the same way.

Packages with recent CVEs are indeed a known issue with this - ideally audits should ignore the minimum age, and there should be a way to override the minimum age per package. But at least for npm the core feature was seen as more important than those extensions.

Some comparisons:

• pnpm uses minimumReleaseAge and minimumReleaseAgeExclude (which takes a list of package names with optional version numbers to exclude specific versions)
• uv uses exclude-newer and exclude-newer-package (which sets the minimum age or disables it per package)

[krnlde]

This should get more attention due to the recent supply chain attacks. It's just a matter of "when" not "if".

[mdevolde]

Kai Dorschner (@krnlde) I'll look back at my PR soon, but I need to find solutions for sources like msstore, for which I haven't found reliable information on release dates. Any idea about that could be very helpful.