Hi Fritz,

Thanks for reporting this; the underlying with the Packages index file isn't so much the migration, but the code that generates the index file on the new feed.

Basically, the control files seem to be have an extra new line that isn't being trimmed. The old feed code must have removed them.

Anyways we will address this via PG-2985 in the next maintenance release or you can try the proget.inedo.com/productimages/inedo/proget:24.0.37-ci.2 container now.

Cheers,
Alana

Hi @tames_0545 ,

Sorry, no idea -- there is definitely something wrong with your environment but aside from the advice I gave earlier, I don't have any other troubleshooting steps. You may want to try a different environment / Docker host.

As I mentioned, it could something wrong with your database mount (/opt/proget/database) -- maybe that is getting deleted? Or it could be your security configuration that is interfering with the running container. We have seen some hyper-aggressive security tools that make things so secure nothing runs.

Thanks,
Alana

Hi @kc_2466 ,

Understood, that was the same reason given before.

Our products' AD/LDAP integration works different than JIRA/TeamCity (live lookup vs sync) so it's just not that simple.

We're not willing to add complexity to work-around "dumb" organizational policies -- what you described is the whole point of AD/LDAP (centrally administered access).

It's possible to delegate group administration in AD, but if they don't want to do that... I guess they are okay with you just creating less-secure built-in users until they get around to completing their tickets ;)

Thanks,
Alana

@misael-esperanzate_5668 thanks for the reproduction details!

I was ablet to reproduce this very easily and fixed it via PG-3091 - it was an ordering problem

This will be in the upcoming maintenance release this Friday

Hi @james-woods_8996 ,

I looked into this a little more, and it turns out that our cloud storage providers do in fact support chunking -- but the outgoing replication code is not taking advantage of that. We would like to fix that in ProGet 2026.

However, in the meantime, we can fix the incoming replication code (i.e. what's throwing the error) pretty easily via PG-3102 - hopefully we'll get that in the upcoming maintenance release.

Thanks,
Alana

Hi @mmaharjan_0067

The "unexpected argument" running without quotes is expected, but it works fine when I run with quotes. I'm afraid I can't reproduce this.

I would check under Admin > Diagnostic Center to see if anythings logged. Alternatively, you may need to query the API by doing something like this:

curl http://server:8624/endpoints/Test/metadata/metadata-test/v1/1%20-%20Normal.txt

Thanks,
Alana

@jfullmer_7346 thanks! As an FYI...

• Names and Versions are centrally indexed, and were intended to be "write-only" by design
• NuGet does not have case-sensitive names, but some earlier bugs allowed duplicate names to be created
• we are adding Duplicate Names (e.g. winscp and WinSCP) and Duplicate Versions (e.g. winscp-4.0.0 and WinSCP-4.0.0 checking to feed integrity
• When re-indexing a feed, you'll get an option to de-duplicate names/versions, which will fix it across all feeds
• Pulling or Publishing a package will update the casing of a centrally-indexed name
• Also we're getting rid of the concept of "Noncannonical Names" altogether, since we've discovered many NuGet packages "change casing" at some version

@uli_2533 thanks for the additional info, great find in the source code too!!

On our end, I was looking at the PUT code, where a 301 kind of made sense. I think it must have been some kind of regression on the GET request? Not sure why it didn't get noticed before, but it's a trivial fix.

PG-3108 will be in the next maintenance release (Sep 19)... or if you want to try it now, it's in inedo/proget:25.0.10-ci.9 Docker image.

Thanks,
Alana

Hi @jfullmer_7346 ,

I haven't had a chance to look into more details, but thanks for providing the results of the query.

FYI - the PackageNameIds and PackageVersionIds are designed as a kind of "permanent, read-only record" -- once added they are not deleted or modified. Even if all packages are deleted (i.e. FeedPackageVersions). This is why this the "duplicate name" is such a headache to deal with.

That said, on a quick glance, we can see exactly where the error is coming from: there are duplicate versions (i.e. (ID=563)-v6.5.3 and (ID=562)-v6.5.3). So, when we try to deduplicate (ID=563) and (ID=562) (i.e. winscp and WinSCP), we get the error as expected.

What's not expected is that those versions were not de-duplicated in the earlier pass. My guess is that it's related to winscp being in one feed and WinSCP being in the other -- we tried to be conservative, and keep the de-duplication to packages related to the feed.

I'm thinking we just change that logic to "all packages of the feed type". Anyway, please stay tuned. We'll try to get it in the next maintencne release.

Thanks,
Alana

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 @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 @d-mischke_3966 ,

I don't really know... based on the url it does like V1 to me, but the response looks like V2 API looks like (it's an ODATA/RSS style). I don't know what V1 looks like, it's before all of our times :)

Anyway I would ask them to investigate the issue. V2 has been deprecated for over 5 years now, so we don't wanna make changes, especially to work-around a "bad" third-party feed.

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 @mikael ,

Oh sorry, we decided not to refactor/rewrite the API after all -- and I guess we threw out all the "ideas" attached to that initiative as well. This was on our roadmap for several years, so we didn't realize there was a customer-facing request attached, hence how so we forgot.

Anyway, I've moved this back as feature request, and we'll look to add this to the existing API. It probably won't be that bad! Please stay tuned, hopefully we'll evaluate within the next couple weeks.

Cheers,
Alana

Hi @Nils-Nilsson ,

Good news - this is actually on our ProGet 2026 roadmap.

The general idea is to "reuse" Feed Groups -- I guess we'd call them "Feed & Project Groups" or something? Anyway, the projects would be grouped in the UI similarly, and you could scope project-based permissions to a group.

We will try to get it as a preview feature in the coming weeks, assuming it can be done in low risk. It seems like this would be the case.

Cheers,
Alana

Hi @joshua-mitchell_8090 ,

Thanks for the inquiry! The changes are available in the inedo/proget:25.0.24-ci.4 container image, and we'd love to get a second set of eyes. Are you using Docker?

They're relatively simple, but we just avoid changing stuff like this in maintenance releases... so it's currently slated for ProGet 2026.

But it should be okay for a maintenance release. Please let us know, we'll decide to release based on your or other user feedback.

Here's what we changed.

First, we added a "sixth" component called IncrementalVersion2 that will support versions like 1.2.3.4-mybuild-678 (where 4 is the second incrementing version), so that vulnerability identification can work better. Our implementation is based on the the Maven version specs, which in retrospect, seems to be followed only by ProGet. Pretty low risk here.

Second, we changed our "path parsing" logic, which identifies the groupId, artifactId, version, artifactType from a string like /junit/junit/4.8.2/junit-4.8.2.jar into /mygroup/more-group/group-42/my-artifact/1.0-SNAPSHOT/maven-metadata.xml.

It's a little hard to explain, so I'll just share the new and old logic:

//OLD: if (urlPartsQ.TryPeek(out string? maybeVersion) && char.IsNumber(maybeVersion, 0))
if (urlPartsQ.TryPeek(out string? maybeVersion) && (
    char.IsNumber(maybeVersion, 0)
    || maybeVersion.EndsWith("-SNAPSHOT", StringComparison.OrdinalIgnoreCase)
    || (this.FileName is not null && !this.FileName.Equals("maven-metadata.xml", StringComparison.OrdinalIgnoreCase))
    ))
{
    this.Version = maybeVersion;
    urlPartsQ.Pop();
}

Long story short, this seems to work fine for v8.5.0 and shouldn't break unless someone is uploading improperly named artifact files (e.g. my-group/my-artifact/version-1000/maven-metadata.xml or e.g. my-photo/cool-snapshot/hello-kitty.jpg).

Thanks,
Alana

Hi @denis-krienbuehl_4885 ,

Thanks for checking; for a short-term like this no problem!

Cheers,
Alana

Hi @Ashley,

Thanks for testing it! That was the intended behavior here - to count "days" not "24H blocks". That's a more intuitive pattern in general, as people think "the next day" or "a few days later" and don't really consider the time.

That does lead to some strange behaviors like 2026-05-03 23:59:59 to 2026-05-04 to 00:00:01 being considered "1 day". However, in this use case, I guess we're talking just a difference of hours which isn't going to make a package any "safer" realistically.

Thanks,
Alana

PS good catch on typo, I adjusted it on 2026 branch.

Hi @pg_user_8607 ,

Nice find with that image; that makes it easier to demonstrate :)

This is unfortunately another "weird docker thing" that would requires a substantial amount of internal model changes to properly address. That's not on our roadmap at this time.

The image you found (inedo/buildmaster:25.0.12) is a so-called "fat manifest" (i.e. a manifest that points to another manifest). As such, there are zero layers (blobs) and thus the sum of all blob sizes is zero.

The 25.0.12 manifest points to e84148156b3e, which is an untagged image. You can see this on the "Sub Images" page:

The /containers page does not show untagged images.

In the past, "fat manifests" were rare - but the default Docker build tools default to create fat manifests, even if there's only one image. It's something we will likely address down the line, it's just not in the roadmap now.

Thanks,
Alana

Hi @amy.j ,

If the package is already cached in ProGet, then the publish date is already set. So, i would make sure to delete the package and try it again.

Otherwise, can you share more specifics? That way we can create a reproduction case.

Thanks,
Alana