Thoughts on Repology report

[denelon]

Hey everyone, some of you may have noticed that we've added the Repology badge on the main readme.

Some confusion has come out of doing that.
It looks like if we have both the current and outdated versions of packages, that they show up counted in both categories.

We've also seen the "Vulnerable" category associated with CVE data. I know there is a lot of value in having older versions of some packages, but certainly not "all" packages need to have the entire history available. We're thinking about pruning a bunch of the older versions of packages with CVE's reported. I'd love to get some feedback from the community here about our options.

Longer term, I've been thinking about a way to have WinGet provide some data for packages with known vulnerabilities and possibly a link to the report(s) if possible. There are also some interesting things we could do if you run "list" or "upgrade" in terms of declaring potentially vulnerable application versions installed.

In the short term, I'd like to get opinions about how we might go about pruning the majority of the packages with CVEs assuming it's not the latest version.

We might not want to do this for Runtimes or SDKs in all cases, however, so I'm open to some discussion here.

[Trenly]

There are a few issues that I see with Repology -

• Versions being listed as outdated - where WinGet wants to keep the old versions, they would need to be explicitly marked as legacy in the Repology ruleset. Every time a new version is added to WinGet, the newly outdated version would need a PR to be marked as legacy in Repology. Either that, or WinGet should only be keeping the latest version of packages, which seems to defeat part of the ideology of WinGet
• Packages being mismapped - Repology doesn't always map package IDs correctly, especially when the names are close. A rule has to be submitted to Repology to disambiguate the package
• Package versions not being marked as Dev / Alpha - Similar to the packages being mismapped, if a version is a dev version or an alpha version a new rule has to be submitted to Repology for that version or a regex match for a version pattern
• Packages not being in Repology - According to Repology we have 2220 packages, when in reality we have almost 6000 (5943), granted some of the packages are alpha / beta / canary release channels, but certainly not 3000 of them. Detection rules for the missing packages would have to be submitted to Repology for the missing packages

There are certainly benefits to Repology too -

• Easier to see when other repos have adopted newer versions
• First step towards having CVE data

---

To answer specifically the question about how to prune packages with CVEs, I think the first step is to get the list of Repology Packages and what Package Identifier(s) they tie back to here at WinGet. For example 7Zip at Repology corresponds to 7zip.7zip, 7zip.7zip.Alpha.exe, and 7zip.7zip.Alpha.msi here at WinGet. Then, we can take a look at which identifiers at Repology are reporting CVE's and which versions, then remove those manifests from the repo.

I've done some proof of concept work that allows for checking which versions in the WinGet repository are marked as vulnerable in Repology, but it seems that Repology recently upgraded to TLS 1.3 which isn't yet supported on Windows 10 GA. However, using the proof of concept, it would be fairly easy to automate checking for and removing versions with vulnerabilities once the list of Repology ID <==> WinGet ID is known

[denelon]

I have some great news to share. We've got another internal team working on mapping CVE data to WinGet packages. We will likely handle these the same way we handle icons (behind the scenes). Some early thinking is that we would update manifests with CVE data and expand WinGet capabilities to have the ability to interactively prompt when a CVE is present, and arguments/settings for how users want to deal with packages associated with a known CVE.

Users may still want or need to install a version of a package with a CVE for regression or compatibility reasons for a period of time and WinGet shouldn't prevent that from being possible, but in most cases, we shouldn't just silently install something with a potential vulnerability without user consent.