[New Feature]: Add security related metadata on manifest files.

[DumboJetEngine]

Description of the new feature/enhancement

Looking at the existing manifest files, I begin to realize that you are missing the most important feature I want in a package manager:
The distinction between different update types (security fix, functionality fix, feature update).
I want the package manager to be able to auto-update only the packages that have security fixes (although, someone else might want to also include functionality fixes).
If it can adjust its behavior on a per-package basis too, in the form of an override, it might be even better.

Proposed technical implementation details (optional)

Allow a field in the manifest file that specifies the update type (e.g., critical risk security fix, medium risk security fix, low risk security fix, functionality fix, feature update). This will be set by the author.
Also, you can (and should) probably allow a combination of update types per package version (e.g. security fix and feature update at the same time).
When exploits for a piece of software comes out, you could auto-update the existing manifest files (and the field mentioned above) for all versions of the software, without the author having to do anything. I believe that all exploit databases out there do specify which versions are affected by an exploit, so this should be easy. And the package manager could retrieve, display, and act upon this information.

P.S. :
You could also include more metadata, like the type of software (GUI app, command-line app, SDK, driver, firmware, codec, font, etc).
Also, the target OS name, just to be flexible. E.g. "above Windows 7", "above Win10", "Windows Nano (which we all hope gets resurrected...)", Linux, etc.
Also, software/hardware dependencies, like DirectX9, MSVS C++, TPM 2, etc.
Amount of required RAM/disk, etc.

[stephengillie]

• This would work if these were patches to applications, such as installing Windows Updates. But these are full application installs - upgrading means sometimes uninstalling the old version, then installing the new version.
• Developers don't provide this data in a consistent manner.
• Release notes containing details of the changes since the last version are sometimes added in the Description field. Should there be a ReleaseNotes field to encourage this?
• For a new user who hasn't used a piece of software before, the UpgradeType might be confusing - would they want to install the "critical fix" version of the application? Or the latest version which is only marked "feature update"?

You could also include more metadata, like the type of software (GUI app, command-line app, SDK, driver, firmware, codec, font, etc).

• ApplicationType could be a new field, and might help the pipelines to handle tray and CLI applications better.

Also, the target OS name, just to be flexible. E.g. "above Windows 7", "above Win10", "Windows Nano (which we all hope gets resurrected...)", Linux, etc.

• This is covered by the MinimumOSRequired and proposal for MaximumOSRequired fields. I don't know about plans for Linux implementations, but an OSFlavor or similar field would be needed.

Also, software/hardware dependencies, like DirectX9, MSVS C++, TPM 2, etc.

• Dependencies have been supported for about a year. Windows Features as dependencies were added more recently.

Amount of required RAM/disk, etc.

This might be useful for larger packages. I've been doing this inconsistently with the 1GB+ This package is 1 GB or larger. label.

[Trenly]

• Release notes containing details of the changes since the last version are sometimes added in the Description field. Should there be a ReleaseNotes field to encourage this?

There is already ReleaseNotes and ReleaseNotesUrl in the locale manifests

[DumboJetEngine]

This would work if these were patches to applications, such as installing Windows Updates. But these are full application installs - upgrading means sometimes uninstalling the old version, then installing the new version.

For a new user who hasn't used a piece of software before, the UpgradeType might be confusing -
would they want to install the "critical fix" version of the application? Or the latest version which is only marked "feature update"?

Even when uninstalling the old version to install the new, what matters to the user (or the package manager that will do the auto-upgrade) is whether the upgrade from the old version to the new patches a vulnerability, and how urgent this patch is.

What the user (or the package manager) will see, is a cumulative evaluation of the fixes, from the old version up to the target version. So, if the user has version v0 installed, version v1 reports fixing a critical vulnerability, v2 reports fixing a low-risk vulnerability, and v3 reports nothing, then v0 has at least 1 critical and at least 1 low-risk vulnerability, v1 has at least 1 low-risk vulnerability, and v2 & v3 have no known vulnerabilities. The same logic can be applied to functionality fixes and features releases. If there was an auto-upgrade feature, the package manager would choose to upgrade you from v0 to the latest version automatically (taking into account any package settings that might be overriding the global settings). If you were on v2, the package manager would not need to update the package, unless you told it to do so for the particular package.
To update the manifest from a CVE database, you need to grab all the CVEs for that software, see at which version a particular CVE gets fixed, and update the manifest files for each version to contain the appropriate security fix rank (critical, medium, low).

This could also work the other way around when it comes to security fixes, and have CVEs embedded in the manifest file. CVEs will be fetched from CVE databases and inserted into the manifest automatically for each version. Then, each version will have its vulnerabilities embedded into its manifest file for the package manager to access. But this will be a problem for vulnerabilities that have no public CVEs. Perhaps in that case a random CVE could be assigned and be added manually by the publisher, but he would have to update all the appropriate previous versions of the package (which is a larger pain, if you ask me). Also, this cannot support functionality fixes, nor can it mark a release as a feature upgrade.

Of course, the publisher of the software would have to be responsible, and use this properly. But that is a general problem when it comes to fixing vulnerabilities. I think that any publisher responsible enough to issue security patches, would be responsible enough to check a few checkboxes about it. After all, most software on Windows is published by large corporations that try or claim to be responsible on these matters. And even if they don't fill the required information of any of the two methods mentioned above, at least it can work automatically with public CVEs when the publishers don't play ball.

There is so mush software installed on modern OSes, that going through release notes is not very feasible. I never do that, unless I am in love with the software in question. Having an overview in the form an "update type" (critical-risk security fix, medium-risk security fix, low-risk security fix, functionality fix, feature update) is a good way to help the user out, and even more to automate the upgrades, which is the most important thing when it comes to securing a computer. Installing everything indiscriminately is a horrible idea since there is software that require many GBs of data to be downloaded and installed (which is the sad situation in Linux snaps). And letting the user manually go through the apps, read their release notes, and decide what to upgrade (which will never happen anyway...) leaves time for a possible attack.