Way to classify an update as critical / security / etc.

[chucker]

I've started using Chocolatey combined with Icinga (a Nagios fork) as a way to monitor which applications need updating on remote machines. Much of the time, this results in interesting, but noisy information, e.g.:

4 update[s] available: 
grepwin: v1.6.7 => 1.6.7.20150427
winscp: v5.7 => 5.7.2
sysinternals: v2015.03.10 => 2015.04.20
bowpad: v2.0.19 => 2.0.20

Now, that WinSCP update does in fact include security patches, but other than that, these are probably minor and needn't be installed urgently.

But then there's also this one:

1 update[s] available: 
flashplayeractivex: v17.0.0.169 => 17.0.0.188

Leaving aside why in the world Flash Player would be installed on a server in the first place ;-), this one's far more important to keep a look at.

So, a bit like Windows Update has the UpdateClassification enum, I'd like to propose the ability to mark the classification / severity of an update.

Chocolatey would then have to find the highest severity between the locally installed version and the newest available version. (E.g., if WinSCP 5.7 is installed, 5.7.2 is available and doesn't contain security fixes, but 5.7.1 in between did, it should either offer 5.7.1, or mark 5.7.2 as critical.)

[ferventcoder]

This is interesting, I see it needing to come from the package itself, which means it is blocked by being able to change the package metadata (aka enhance the nuspec).

[ferventcoder]

Then there is also package indexes I feel would need to come in front of this.

[ferventcoder]

Chocolatey would then have to find the highest severity between the locally installed version and the newest available version. (E.g., if WinSCP 5.7 is installed, 5.7.2 is available and doesn't contain security fixes, but 5.7.1 in between did, it should either offer 5.7.1, or mark 5.7.2 as critical.)

This is why package indexes would need to come before. This could be quite a bit of data mining, not something you want happening on the server.

[ferventcoder]

How would you see the update classification get marked? By the package maintainers? By the moderators? Just out of curiosity, it could be subjective.

[chucker]

How would you see the update get marked? By the package maintainers? By the moderators?

The maintainers, I'd say. (Perhaps a moderator would have to be able to override if, say, a maintainer is a bit overzealous with considering their updates 'important'?)

It's not a fail-safe system, of course, but since e.g. bowpad is maintained by the developer himself, he'd know how to properly classify his updates. Conversely, the maintainer of e.g. filezilla.server would keep an extra eye on vulnerabilities.

[ferventcoder]

Yeah. Just some definite design considerations to be had.

[wjk]

Have you considered using a (for example) changelog.xml file in the nupkg? This file would list such a severity flag such as is being discussed for the current version, and all previous versions. (For example, when package version 5.7.2 is released, the data for versions 5.7.1 and 5.7 would not be deleted in the process. This would make checking to see if an intermediate update contained critical fixes far easier, as it could be done entirely on the client side.) Of course, if someone comes up with a better idea later this system could be deprecated and replaced. I'd be willing to provide a PR if you find this a usable solution.

[ferventcoder]

@wjk how is this different from the release notes that is currently available in the nuspec?

I believe that information is available in choco list pkg -verbose, we should make it available from choco outdated as well.

[wjk]

I did not intend for my XML file to replace the nuspec's release notes field, only to supplement it. The only reason I suggested a separate file in the first place is because doing it this way enables this feature to ship without having to wait for e.g. #205 or #325 to be completed, as those issues may take a while before they are resolved.

[ferventcoder]

@wjk - #205 has shipped. And it is true that enhancing the nuspec takes alot of coordination between the nuget fork, chocolatey and chocolatey.org. But you can't get communication about the severity in any good way without having it available from the server as a field.

[wjk]

Fair enough; you know these things far better than I. Feel free to disregard my proposal; I just wanted to get my 2¢ in.

[ferventcoder]

With a changelog.xml the only way to get information from it is to --noop and have it report (or add a command to do so).

[thawkins]

Has there been any movement on this at all. All the linux package managers do this, and it allows scheduled "security" updates to be handled. Ultimatly you should be able to do an "update" with something like --security-updates=critical to deternine what security category the update selected is.

[pauby]

As was mentioned above, this is waiting on package indexes before it would be considered.

This is something that would need to come from the community maintainer who would need to evaluate each release, and update the package with the release severity in the metadata. As was also mentioned above, the community moderator would be able to override this, and I'm assuming, set this if it's missing. That would require the community moderator to evaluate each release and determine if the community maintainer made the right call, or make the call themselves.

As a lot of community package update submissions are automated, such as the Chocolatey Community Chocolatey Packages repository, community maintainers are hands-off a lot of their package updates and therefore those packages wouldn't be updated.

As we automate more and more of the package moderation process, package submissions will be checked and approved based on criteria. A human moderator would not see those packages. We already have some of that automation in place.

Given all of the above, the number of packages that would have an 'update severity' would be small and, as a result, the usefulness of this would be limited.