PGVC: Blocked packages cannot be unblocked

[sebastian...]

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.

[atripp]

Hi @sebastian ,

What setting do you have for unassessed vulnerabilities? I.e. under SCA > Vulnerabilities> "Vulnerability Download Blocking Configuration" - I'd like to see Global rule and Feed-specific rules (if they exist).

Also, the "Manage Vulnerability Sources" is kind of confusing.

Multiple vulnerability sources are definitely a little weird/confusing, esp if you're familiar w/ ProGet 6 and earlier...

• when there are 0 PGVC sources, a "Enable" dialog is displayed; this adds a source
• if there is 1 PGVC sources, a "Disable" dialog is displayed; this deletes the source
• otherwise, no dialog is shown and you see both in the list

Feeds still need to be associated a vulnerability source, but we now call this association "download blocking".

[sebastian...]

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):

[atripp]

Hi @sebastian ,

That's really strange... I can't reproduce this, and I can't think why it would behave this way. But the logic is kinda complex. I don't think it has to do with a PGVC vs OSS vulnerability though.

I did reproduce another bug...

However, it's related to the "block" global rule it seems:

When I change that to "allow" it works fine. I didn't experiment further, b/c I'd like to repro your specific bug and fix that as well.

Any other input on how to repro would be appreciated; maybe try re-assisng to something else.

Does it work if you override the block at the package level? You may have to pull the package to do that first.

Thanks,
Alana

[sebastian...]

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.

[atripp]

@sebastian thanks, that's what I was hoping you could test :)

Can you check something else: can you actually download the package by the URL directly (i.e. using what the API would do?)

It should work, because I think this is just the UI incorrectly "double checking" against PGVC records. Not sure If I can explain it well, but maybe you can understand code better...

When you download a package, PGVC is first queried and then vulnerability records are added. Then, those added vulnerability records are checked against download rules.

The records are not added while browsing a package, which is why we perform that second check. However, that second check should first cross-reference PGVC records against vulnerability records...

Anyway, I wanted to confirm that was the issue - and then if so, we'll take a stab at fixing this.

[sebastian...]

@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.

[atripp]

@sebastian thanks for confirming!

I've added this as something to fix via PG-2441 and targeted it as 2013.14 (next Friday), but it's a lower-priority issue so it will may get "bumped" to the next or following depending on other issues