@shayde
I can't speak for @atripp and the folks at Inedo, but I can tell you that we have submitted PRs for pgscan via GitHub in the past and they have all been accepted. Caterina and I actually already discussed implementing this, because it doesn't look too complicated, but we probably won't get a chance to look into it closer for a few more days. So if you want to go ahead, I think this would be much appreciated

@atripp
You are correct! I can download the package directly entering the corresponding URL in the browser, so it seems that this indeed just a UI problem.

Hi @atripp

I have tried changing the global rule to "block" and then back to "allow", but it did not change anything. I also tried different assessment, also to no effect. The only thing worth mentioning that comes to mind is that our OSS Index source is still active. I tried deactivating it on our Nuget feed, but again: the package remains blocked.

I am not sure what you mean by "override the block as package level". Do you mean setting the package's status? When I do that (setting "Download allowed" to "Always allow downloads" instead of "Use licensing/vulnerabilities rules"), i can download the package. When I set it back to "Use licensing/vulnerabilities rules", the package is blocked again.

Hi @atripp

unassessed vulnerabilities are not blocked:

The vulnerability in question wasn't unassessed originally, btw. It was correctly auto-assessed to "High Caution", which correctly blocked the download of the package. But when I manually changed this to "Manually Unblocked", I should have been able to download the package. This always worked for vulnerabilities from OSS Index.

Here is a picture of our assessment types if that helps (the first four are automatically applied to vulnerabilities based on their CVSS if they have one):

We are testing the ProGet Vulnerability Central and we are currently running into a problem (ProGet version 2023.13): We have several assessment types that are automatically applied to vulnerabilities, blocking downloads of packages if the CVSS is above a certain threshold. In addition, we have an assessment type called "Manually Unblocked" that we can apply to issues manually if for some reason we want users to be able to download an otherwise blocked package. This works fine for vulnerabilities coming from OSS Index. However, this doesn't seem to work for issues coming from PGCV:

Is there any reason PGVC would behave differently here?

Also, the "Manage Vulnerability Sources" is kind of confusing. When we click on "Configure Download Blocking" and add Feeds to PGCV, it doesn't show up under "Vulnerability Sources". When we add it explicitly (via "add vulnerability source"), it then shows up twice (once as "PGCV" and once with the name we chose). I don't think this is part of the problem, just seems weird.

@stevedennis
Just wanted to let you know that I tested this with 2023.13 and both issues (PG-2426 and PG-2428) do indeed seem to be fixed with this version. However, it took some time for the package's page to show that the package has been deprecated after I downloaded it. I guess the package analyzer had to run to correctly show the package's state?

What's left is some kind of periodic check for updates on a packages' metadata after it has been downloaded. This would be really useful (doesn't have to be daily, once a week would suffice).

BTW: We are currently looking into the API approach that you suggested and one question came up: Is there a way to add custom scheduled jobs to ProGet (like the UpdateChecker or PackageAnalyzer tasks)? If not, could something like that be added via the Inedo.SDK in the future? I know we can just trigger it with a generic job scheduler, but it would be nice to have all ProGet-related maintenance jobs in one place.

Cheers,
Sebastian

Hi @stevedennis

Some additional info: I deleted the package from ProGet's cache again to test the SCA reporting. However, even though the package's info page now shows the deprecation info correctly, I don't see any warning in my SCA report. I then downloaded the package again and wanted to set the status manually to see if that makes any difference. However, I'm somehow too blind to find a "set status" option. I know that when a package has a vulnerability, I can set its status by clicking on a link within the vulnerability message, but I simply can't find such a link/button for a package that doesn't have any vulnerabilities.

One more thing: you mentioned writing our own "package updater" script using ProGet's Common Package API. Is there a way to list all packages that are cached by ProGet? Because those are the only ones I'd want to check for new metadata. Checking every single package on nuget.org and comparing its data to the data provided by ProGet (or vice versa) would be unfeasible.

Hi @stevedennis

Thanks for your reply. I tried to get the deprecation info into ProGet to see how things look like in VS and in the SCA reports, so I deleted the package from my example above from the cache using the "Delete Cached Package" button. Once the package was deleted, I indeed saw the deprecation info on the package's info page:

However, once I downloaded the package from ProGet, it seems the deprecation info was lost:

Same goes for the package from your example (which had not been previously downloaded and cached on our ProGet installation): Once I downloaded the package, the deprecation info is gone. Does that mean that ProGet does not copy NuGet's deprecation info when downloading a package, even when that status is already set at the time of the download? Is this a bug or intended?

Hi there!

It seems like ProGet currently doesn't handle NuGet's package deprecation feature at all. I saw a post from someone asking about deprecating one's own packages in ProGet, but I'm wondering about the handling of deprecated external packages. Would it be possible to have the follwing features in ProGet:

1. Display deprecation info in Proget
   At the very minimum, the package’s deprecated info should be shown at the package’s info page. This includes any additional info that the package’s maintainer provides, e.g. a custom message and a link to an alternate package, if provided. Compare the info shown for Microsoft.AspNetCore in ProGet and on nuget.org:
   
   
   Optionally, the info could also be shown in the search results (see nuget.org as an example):
   

2. The deprecation info should be visible in Visual Studio / dotnet.exe
   Visual Studio warns users if they use deprecated packages when connecting to api.nuget.org:
   
   However, when connecting to ProGet, no warning is shown:
   
   My guess is that this is another part of the nuget API, that is yet to be implemented by ProGet (like the vulnerability info, see PG-2359).

3. SCA Reporting should report deprecated packages
   Just like warnings about vulnerable packages or packages with unwanted licenses, SCA reports should show a warning when deprecated packages / package versions are used by a release.

4. Handle unlisted packages like deprecated packages
   ProGet allows for packages to be unlisted by user. In those cases, it would be nice if the features mentioned above could be applied to unlisted packages as well (display warning in Visual Studio, issues in SCA reports).

I'm aware that this is probably not a trivial request, because NuGet packages can become deprecated after they have been cached by ProGet, in which case ProGet probably won't update the package's metadata. However, there are already some maintenance tasks running regularly within ProGet (like PackageAnalyzer), so maybe it would be possible to regularly check if if the metadata of cached packages is still the same? Or maybe such an update-task actually already exists?

@stevedennis

I submitted a ticket [EDO-9428] for the "unknown license" issue.

I might open another thread for the "partial blocked licenses" issue later, but could you tell me what you mean by disabling the SCA feature in the Feed Features? I don't think I've seen this option in the Feed Features. Also: there are at least two mechanisms in ProGet to block/allow package downloads: license filters and package filters (in the feed's connector settings). What happens when you combine those filters? Is a package always blocked when it is blocked by one mechanism and allowed by the other? What happens if we'd set the default license filter rule to "Block downloads by default" and allow packages like Microsoft.* in the Nuget connector? Could Microsoft.* packages without a known license be downloaded or would they be blocked?

@stevedennis I just noticed that the fix seems to be offered only for "short" versions (i.e. 1.0 to 1.0.0) but not for "long" versions (i.e. 1.0.0.0 to 1.0.0). Is this intended? I think that in cases where the last version part is 0, long versions could be auto-fixed the same way as short version.

Two more thing we noticed in the current version of ProGet (2023.8):

1. Packages with packageid:// type licenses are still reported as "Unknown License". According to PG-2381 this should have been fixed in 2023.7, but it seems that the problem still persists. When I look at the package's page, the (manually applied) license is displayed correctly, but the SCA report still does not recognize it.

2. We have a certain license type which is allowed in some feeds and blocked in other feeds. We do this to make sure that packages with that license are downloaded from the "correct" feed. This has worked fine so far. However, starting with ProGet 2023, all packages with that specific license show up as issues in our SCA reports. How can we get rid of that? Manually resolving those issues is not an option, as we are talking about ~100 affected packages on a project with daily builds.

@v-makkenze_6348
We have seen similar issues in our projects. In most of our cases, the problem was that the "missing" packages had different versions numbers (not using the Semantic Version MAJOR.MINOR.PATCH pattern). E.g. Owin's version is actually 1.0 instead of 1.0.0 and Microsoft.Web.Infrastructure's version is 1.0.0.0 instead of 1.0.0. It seems that ProGet has problems matching those packages.

We resolved this by creating a legacy feed, manually editing the metadata of those packages and re-uploading them to that feed. The ProGet documentation seems to recommend something similar. It seems that there is a build-in function to do something like that in 2023.7, at least I think I saw something like that popping up when I opened the page of the Owin package in the latest ProGet version. I haven't seen any documentation on this feature yet, though. Maybe the folks from Inedo can shed some light on this.

Hi @apxltd,

Wow, that was fast... I noticed that this was apparently already implemented in 2023.5 (PG-2359). Just wanted to let you know that I tested this with 2023.6 and it works like a charm

@apxltd said in Questions about the new ProGet Vulnerability Central (PGVC):

As for Visual Studio, one of our engineers here just prototyped that, and I think we'll do it. That's much simpler and easy to sneak in a maintenance release :)

Sounds great, looking forward to it

Hi @apxltd,

I think having scores is crucial. Otherwise we would have to manually assess a lot of vulnerabilities by hand.

CVE-IDs aren't really that important. I guess we would only use them to find more information on the issue by Googling them. What would be nice: having links to sources, like a GitHub advisory entry, an NVD entry, ...

CWEs might become interesting at some point, if those would become available as a separate field. One could think of some kind of statistics on categories of vulnerabilities.

One more thing we noticed, but this is a general problem, not related to PGVC per se: I can't see information on vulnerabilities or deprecated packaged in Visual Studio. Nuget added support for vulnerabilities about 2 years ago. As a result, the dotnet client or Visual Studio can display on vulnerabilities of packages.

When I look at the same solution and list of packages using our Nuget proxy feed in ProGet, I don't seen any of that info:

I would assume that Nuget expanded their API to support this at some point and ProGet does not support that functionality yet. Are their any plans to support this?

@stevedennis said in Questions about the new ProGet Vulnerability Central (PGVC):

[2] 274/566 seems awfully high; several do not have scores, but since we have to compute the score ourselves with equations like these, it's very possible that the underlying data isn't formatted perfect or there's a bug somewhere -- can you share the examples you found so we can investigate?

Sure, what do you need? Here is a little snippet from the Vulnerabilities_Extended view, filtered on Score is null:

External_Id	Package_Name	Package_Versions	Title_Text

GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.App.Runtime.win-x64	>=3.1.0 <3.1.1	Denial of service in ASP.NET Core
GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.App.Runtime.win-x86	>=3.1.0 <3.1.1	Denial of service in ASP.NET Core
GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.Http.Connections	>=1.0.0 <1.0.15	Denial of service in ASP.NET Core
GHSA-2c7v-qcjp-4mg2	Microsoft.WindowsDesktop.App.Runtime.win-x64	>=7.0.0 <7.0.1	.NET Remote Code Execution Vulnerability
GHSA-2c7v-qcjp-4mg2	Microsoft.WindowsDesktop.App.Runtime.win-x86	>=7.0.0 <7.0.1	.NET Remote Code Execution Vulnerability
GHSA-2xjx-v99w-gqf3	Microsoft.NETCore.App	>=2.2.0 <2.2.1	Exposure of Sensitive Information in System.Net.Http
GHSA-35hc-x2cw-2j4v	System.Security.Cryptography.Xml	<4.4.2	Denial of service vulnerability exists when .NET and .NET Core improperly process XML documents
GHSA-365p-96qv-xr7g	Microsoft.AspNetCore.HttpOverrides	>=2.0.0 <2.0.2	ASP.NET Core allow an elevation of privilege
GHSA-365p-96qv-xr7g	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.0.0 <2.0.2	ASP.NET Core allow an elevation of privilege
GHSA-3m2r-q8x3-xmf7	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.0.0 <2.0.3	Moderate severity vulnerability that affects Microsoft.AspNetCore.All, Microsoft.AspNetCore.Server.Kestrel.Core, Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions, and Microsoft.AspNetCore.Se
GHSA-3m2r-q8x3-xmf7	Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions	>=2.0.0 <2.0.3	Moderate severity vulnerability that affects Microsoft.AspNetCore.All, Microsoft.AspNetCore.Server.Kestrel.Core, Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions, and Microsoft.AspNetCore.Se
GHSA-3rp6-rjw4-cq39	Microsoft.AspNetCore.Mvc.Core	>=1.1.0 <1.1.6	Cross-origin Resource Sharing bypass in ASP.NET Core
GHSA-3rp6-rjw4-cq39	Microsoft.AspNetCore.Mvc.Cors	>=1.1.0 <1.1.6	Cross-origin Resource Sharing bypass in ASP.NET Core
GHSA-3wcj-rg8q-9cqv	Microsoft.AspNetCore.Mvc.Core	>=2.0.0 <2.0.1	Open redirect in ASP.NET Core
GHSA-5633-f33j-c6f7	Microsoft.NETCore.App	>=2.1.0 <2.1.7	Tampering vulnerability in .NET Core
GHSA-5f2m-466j-3848	System.Private.Uri	>=4.3.0 <4.3.2	Denial of service in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.App.Runtime.win-x64	>=3.1.0 <3.1.1	Remote code execution in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.App.Runtime.win-x86	>=3.1.0 <3.1.1	Remote code execution in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.Http.Connections	>=1.0.0 <1.0.15	Remote code execution in ASP.NET Core
GHSA-6px8-22w5-w334	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.1.0 <2.1.7	Denial of service in ASP.NET Core

Googling the External_Id of the first entry (GHSA-23cv-jh4v-vffm) leads me to this GitHub Advisories entry, which links to this NVD entry, which mentions a score of 7.5.
If you need more data, I can submit a support ticket and upload an export there.

Hi @stevedennis,

I have enabled PGVC, but the outcome was not exactly as expected:

1. I activated PGVC for our Nuget feed, but I did not delete the OSS Index source, because I wanted a side-by-side comparison of the vulnerabilities. Yet, all my OSS Index vulnerabilities are gone (even the ones for our npm feed).

2. Almost half (274 out of 566) of the vulnerabilities reported by PGVC do not have a CVSS score (OSS Index vulnerabilities almost always have a CVSS score). As a consequence, those vulnerabilities are not automatically assessed.

3. PGVC vulnerabilities do not display the CVE number or a CWE, and in many cases do not provide links to external sources like the NVD.

Is all of that intended and by design?

Hi @stevedennis,

thanks for the quick reply. I was just confused, because all of our vulnerabilities seem to have CVE IDs, so I thought that all of them should be suitable for matching between different sources. But given that there seem to be only 5 manually assessed vulnerabilities left, I guess there isn't really much to actually migrate. We'll try simply switching from OSS Index to PGVC and see what happens...

Hi @atripp,

I just tested the implementation of this with ProGet 2023.1 with the aforementioned atob npm package. The filtering works perfect. The package uses "MIT OR Apache-2.0", and as long as at least one of those two licenses is configured as allowed, the package can be downloaded. Only when both licenses are configured as "blocked", the package is also blocked. This works 100% as expected!

When I check the general page of the atob package, "License Information" on the "Overview" tab displays both licenses and their corresponding blocking configurations correctly.

However, when I go to a specific version, the version's "Overview" tab will always state This package has a MIT license, and may be used because of configured license filtering policies, even if MIT is actually blocked and only Apache-2.0 is allowed. This only changes when both licenses are blocked (In which case the page states Packages with the MIT license cannot be downloaded due to a global license rule).

Looks like this is just optics. As I said, the blocking itself seems to work exactly as expected.

Hi @stevedennis,

I'm not looking for a 100% perfect migration. Basically, I have a certain number of automatically and manually assessed vulnerabilities, and I would like to keep those assessments, wherever the same vulnerability exists in PGVC. In detail: I'm fine with "loosing" all OSS Index vulnerabilities. I'm also fine with seeing a larger number of new PGVC vulnerabilities after switching from OSS Index to PGVC, even if those aren't really "new", but already existed as an OSS Index vulnerability. What I would expect from a migration is this:

1. Auto assess all new PGVC vulnerabilities based on the "Auto assess" option configured for assessment types (I guess this should work anyway and have nothing to do with migrating from one source to another).
2. If a PGVC vulnerability can be matched to an OSS Index vulnerability (based on a CVE number), apply the assessment of the old vulnerability to the new one. If it can't be matched, rule 1 applies.

However, as I was writing this, I was having a look at our current list of vulnerabilities and it looks like we have lost a larger number of them. I currently only have 182 vulnerabilities, and only 5 of those are manually assessed. Is there any mechanism that deletes old vulnerabilities? I know for a fact that I have manually assessed way more vulnerabilities than that to unblock the corresponding packages. None of our assessment types have an expiration, but those should only remove the assessment, not the vulnerability itself, right?