Best posts made by atripp

Hi @jfullmer_7346,

It's nothing you did.

The underlying issue is that a bug in ProGet allowed WinSCP (ID=563) to be added to the PackageNameIds table; that should never have happened since nuget is case insensitive. We've since fixed that bug.

However, once you have a duplicate name, weird things happen since querying for "give me the PackageID for nuget://winscp" returns two results instead of one. So now when you query "give me the VersionID for (ID=563)-v6.5.3", a new entry is created.

This has been a very long-standing issue, but there aren't any major consequences to these "weird things" except casing in the UI and the health check now fails.

But we're on it :)

Thanks,
Alana

Hi @carl-westman_8110 ,

The error message means that the database wasn't updated as per normal during the start-up process. It's hard to guess why, as we have special handling for that.

It's likely that restarting the service would have fixed it, but downgrading and then upgrading would also force an upgrade as well. Unfortunately it's hard to say at this point.

Upgrading to 2025.10 should be fine.

Thanks,
Alana

Hi @fabrice-mejean ,

It's no longer possible to query this information from the database.

As you've noticed, ProGet now uses a version range (i.e. AffectedVersions_Text ) to determine whether a package is vulnerable or not. So instead of 4.2.3 it's now 4.2.3-4.2.8 or [4.2.*) or something like that.

Unfortunately it's not practical/feasible to parse this information unless you were to rewrite a substantial amount of ecosystem-specific parsing logic - this would be basically impossible to do in a SQL query.

Instead, you'll need to use the upcoming pgutil packages meatdata command to see what vulnerabilities a particular packages has. You can also use Notifiers to address newly-discovered vulnerabilities.

Thanks,
Alana

Hi @geraldizo_0690 ,

Thanks! And we appreciate your ideas/suggestion and detailed guidance on how to implement it.

It seems really simple and should be available in the upcoming maintenance release (next Friday) via PG-3196 -- we can also let you know when a prerelease is available if you wanted to try it sooner than that.

Cheers,
Alana

Hi @jonathan-werder_8656,

Oooh that's definitely outdated, thanks for pointing that out! Perhaps we should just delete that article.... but I'll see if we can salvage it.

If you're setting up a new instance of ProGet, that article is not for you -- that's helping you migrate an existing instance. For a new instance, I would just do a standard Windows or Linux installation (use the Embedded database in either case) - there's nothing special about Azure.

For migrating... at this point (i.e. ProGet 2025+), I would just set-up ProGet on the new server using PostgreSQL (the default configuration). Then, export your database from the old server and import it into the new server.

You'll have to deal with the Package Files as well, which is discussed in this (slightly outdated) Migrate an Existing ProGet Installation to a New Server article.

Anyway we'll add these to the list, but let me know if you have any questions in the meantime.

Cheers,
Alana

Hi @rie_6529 ,

There is not -- this is not an action that should be performed regularly at all. It's more a troubleshooting thing that should only be done after some data problem.

If you find yourself having to run this often, it's indicating there's some other issue. In years past, no one really noticed this (and it didn't have any side-effects), but since we added Integrity Checks, the bad data is a lot more visible.

So it'd be best to troubleshoot that and see if we can correct it.

Thanks,
Alana