ProGet 2025.14: Vulnerability Database Updater causes duplicates in PackageNameIds

jw

As the title says, after running the Vulnerability Database Updater job, duplicates appear in the PackageNameId table.
This results in the feed integrity checker complaining about the duplicates and suggesting a index rebuild with duplicate cleanup, which does not fix this issue permanently.

As a consequence, we found that in the SCA module the license of the package could no longer be detected, even though clicking on the package still navigates to the package page and shows the license as green.

It looks like packages which had their casing changed in the past are the source of this issue. In our case it happens with the jQuery NuGet package which had the "Q" uppercased.

The first row in the screenshot is present before the Vulnerability Database Updater job ran, the 2nd row appears after:

Microsoft.NETCore.* are also packages causing this issue, apparently the "NET" was uppercased at some point.

According to the NuGet spec, the package id should be handled case-insensitive. There is also this issue in the purl-spec repo.

Is this an issue in our database or something that needs to be fixed on ProGet side?

stevedennis

Hi @jw ,

Did you try this on a new instance, or did you discover this on your (older) instance?

This was a known issue through several versions of ProGet 2025, and it impacts mostly SCA as you noticed. However, the vuln updater has since been fixed, so it shouldn't be continuing.

The "feed reindex" function can also merge/fix these duplicate names. They should be detected during a "feed integrity" check, and show as a "warning".

Thanks,

jw

Hi @stevedennis

I first noticed the issue on our production instance, which is older installation upgraded to 2025.10. The issue is easily reproducible on my test instance, which was just installed from scratch this September.

With database looking like the screenshot above, I ran the feed reindex with both options checked. Unfortunately that seems to clean up the wrong entry, in this case the ID 68622 gets deleted, which still has the old Package_Name.

After reindexing the integrity check is green as expected, but when I run the Vulnerability Database Updater job, the database looks like this afterwards

Running the feed integrity check again, we are back to where we started:

atripp

Hi @jw ,

Thanks for confirming that; we were able to identify the bug -- this time it ws SQL-server specific.

This is fixed via PG-3163, which we're shipping in this week's maintenance release. You'll still need to de-deduplication after however.

Tanks,
Alana

jw

Hi @atripp

Just tested 2025.15 and the Vulnerability Database Updater does not cause duplications anymore - so thank you for that fix!

A small semi-related issue:

The deduplication during reindex does remove the duplicate entries, but it always leaves the entry with the wrong (old) package name behind.

E.g. when I have no jQuery package in the cache everything looks correct, most likely because the package name is taken directly from the feed:

When I download the package and it gets cached, the database entry seems to take over causing the old package name to be displayed:

Is there any way I can update these packages with changed names to use the newer one?
Maybe this could be an option during reindex?

atripp

Hi @jw,

Unfortunately there's no easy way to guess which name is "correct", so sometimes the "wrong" name gets de-duplicated. This also should have no real side-effect, except perhaps seeing the "wrong" casing in some places.

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This doesn't seem to impact many packages at all.

Thanks,
Alana

jw

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This was a pretty good hint. So far I've only been hitting the "Download Package" button, which puts the package in the cache, but apparently does not update the name in PackageNameIds. "Pull to ProGet" however seems to update that table and I can fix the old names in the database.

Thank you!

jw

There might be a regression from the recent fixes for the issue in this thread.

One of the packages with changed names is Microsoft.NETCore.App.Runtime.win-x64 (the "NetCore" part is different now).

Recent vulnerabilities, like PGV-2576347, are no longer matched to recent package versions.

Flagging stops at the 8.0.2 version but should go up to 8.0.20.

Any chance that these package names are compared case-sensitive against the PGV database which breaks the matching for renamed packages?

atripp

Hi @jw ,

Thanks for finding this; we'll get it fixed via PG-3180; it was problem when updating the vulnerability database and related to the case matching again. Hopefully this is the last place.

Thanks,
Alana

jw

Hi @atripp

Once again thanks for the quick fix.

I was actually worried that something got messed up in our database, while trying to fix the duplicate package issues, but so far everything looks good.

Also I should probably start making it a habit of stating that we're still on SQL Server, instead of having you guess. ;)