Hi @caterina ,

Glad this is working now! I have no idea what it could have been.... maybe there was some kind of platform/library regression.

We didn't make any WIA/AD/LDAP changes -- just went from .NET8 to .NET10. This stuff is a bit fragile, as you're noticing

Anyway, all good for now! THanks for letting us know

-- Dean

Hi @caterina ,

Based on the output of /debug/integrated-auth, it looks like a token is no longer being passed from the operating system. That would explain why the user is not being found in the directory.

Are you using any kind of reverse proxy in front of ProGet? Such as IIS or something?

-- Dean

Hi @caterina ,

This error means that the token being passed from Windows (e.g. DOMAIN\USER) cannot be found in the active directory. I would check /debug/integrated-auth, which will give some more information about how that's parsed.

There are no changes we made that would cause this to happen, so it's possible it's unrelated (I would try a rollback to make sure). Otherwise, it's a consequence of some library/dependency change in the active directory libraries we use.

Unfortunately, regressions in Microsoft's libraries can be "par for the course" with Windows Integrated Authentication, which is why we recommend moving away from it.

That's not to say it won't work, but the best way to handle this is to disable WIA and set this up from scratch again.

-- Dean

Hi @Ashley,

It wouldn't make sense to try removing "vulnerable packages" from storage -- in fact, even download blocking doesn't make sense in most cases, as it tends to lower the organization's security posture and leads to other problems.

Even the package with the "world's most severe vulnerability" (i.e. the infamous log4shell) is harmless unless it's incorporated in an application in a certain way and the application is exposed in a certain manner that would allow a malicious actor to exploit it. Trying to block access or remove these harmless library files from the network will substantially lower the organization's security posture, for a number of reasons.

I'd encourage you to check out our best practices guide: Vulnerability Management Done Right with ProGet. In particular:

• Preparing for a Category 5 Vulnerability to learn how to handle the "next" severe vulnerability
• Blocking & Containing Vulnerable Packages for general best practices in addressing them in pipelines

I think the Preparing for a Category 5 article will help you create that template process for what to do when that high vulnerability package is is identified.

Hope that helps

-- Dean

HI @ashley,

A package's unlisted state (i.e. "yanked" in PyPi or Ruby) is server-side metadata, similar to download count. That means, once a package moves servers (i.e. from pypi.com to ProGet), that metadata is owned and maintained by the new server. When a package is cached/pulled into ProGet, that state is copied from the remote server.

An unlisted/yanked package may still be downloaded and consumed, and it's up to the client to determine how to use (or not use) packages with that status. ProGet simply displays an "hidden icon" next to unlisted packages. Visual Studio does not display them at all. I would imagine pip doesn't consider them in dependency resolution and might give a warning if consumed directly.

That said, the OSS Metadata Updating & Caching will routinely sync Listed and Deprecated statuses, but it comes at an obvious performance cost. Or you can use retention policies to more aggressively delete cached packages.

Hope that helps.

--Dean

@manuel.riezebosch_8638 the purl argument was never actually read, so you could have really put anything in there :)

It was just one of those docs error; many other api endpoints will use a purl argument

And you're right... all the other package types have metadata inside the package, so that's what's read. Some require a file name, but Debian is an outlier in that it requires a distribution argument as well.

Hi @manuel-riezebosch_8638 ,

It looks like the HTTP Endpoint documentation for the pgutil packages upload command was not accurate. A purl is not used here. I've updated the docs as follows...

---

To upload a package, simply PUT to the URL with a feed name, an appropriate API Key and a package in either ZIP, JAR or TAR format depending on the value of the Content-Type header.

PUT /api/packages/«feed-name»/upload[/«package-file-name»]

The «package-file-name» part of the URL is only required for the PyPI and RPM feed types, while Debian feeds will require a distribution argument and an optional component. See the corresponding upload package method on ProGetClient.cs for the most accurate and up-to-date pgutil and HTTP endpoint argument mapping.

---

Hope that helps!

-- Dean

Hi @Nils-Nilsson ,

It's not really possible to "send a notification" without all the context (like Package Version, Name, etc.), but there is a relatively easy way to test that notifications are being sent (i.e. when you add a package).

If you configure a Email Notifier, you can check off the "Add notification in ProGet". You can enter a "fake email" or not even configure SMTP settings.

When you do that, it will still add a notification to ProGet (under Admin > Notifications) with the same body as the email.

-- Dean

Hi @certificatemanager_4002,

I'm not sure I totally understand the question :)

The ConnectionString property is marked as encrypted, which means that ProGet's Encryption Key will be used to store it to the database as encrypted, and obviously decrypt it.

But this should happen automatic, when using the API or UI to save the settings.

-- Dean

Hi @ybaskar-temp_3339,

Going off of memory here (this was like 10 years ago), but I believe that BuildMaster v5 would hide legacy options unless there was already legacy data. Since there's no legacy plans there's no button.

However, it still should be possible if you can find the url of the page to navigate to. I would check other apps for that option, inspect the url, and just replace it with your applications Id.

Let us know if that works!

-- Dean

@pg_user_8607 very cool, great practical use of the new ".cs scripts" type applications! I think this could make a nice blog post... I'll point this to our technical writers!

Hi @devops_8569 ,

I'm afraid this is a known limitation issue with Maven versions in ProGet for now.

Long story short, ProGet followed these versioning specifications:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

However, some packages did not follow those specifications but instead relied on undocumented quirks (bugs?) in the Maven version parsing. These are now somewhat documented: https://maven.apache.org/pom.html#version-order-specification

It'd be nice to fix, but it would require a risky, non-trivial rewrite of our Maven version parsing to solve this. So far as we can tell, the only consequence is that a small number of vulnerabilities yield false positives. So, it's not a priority.

In ProGet 2026, we are substantially changing vulnerability management so it's likely these false positives won't be an issue anymore. For example, PGV-2314320 would be rated as a PVRS Category 2 for most environments.

We'll evaluate / explore this after getting feedback from users in ProGet 2026, and whether they think it's worth us investing the time/risk to address this limitation.

-- Dean

Hi @parthu-reddy ,

Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what.

As for your configuration...

5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead.

I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard.

It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage.

-- Dean

Hi @parthu-reddy,

Thanks for the detailed investigation notes. From what you've described, the behavior doesn't appear to be related to SQL Server locking. It's most certainly related to blocking/waiting on the 200+ outgoing connections to receive a response from api.nuget.org.

If api.nuget.org is running slow, then ProGet will run slow. There's really no way around this when you use connectors, as ProGet is effectively forwarding client requests.

Most likely, someone or some build server is making legacy/V2 NuGet API requests (they look like ODATA/SQL queries on the url), and those are being forwarded. The V3 requests are just JSON files.

-- Dean

Hi @0xFFFFFFFF,

Thanks for the detailed write-up and explanation.

It looks trivial to add size and upload-time. Adding versions is probably simple, assuming it's just an array of distinct version numbers (we already have all the "packages" in context).

It's probably fine, but just to be safe we will do this in ProGet 2026, given some of the subtle behavioral changes you mentioned ("tools like uv to make use of heuristics to speed up downloads"). For someone with an overloaded server, that might "put it over the edge".

ProGet 2026 may be ready by the end of the month, so it's not so far away.

-- Dean

Hi @Nils-Nilsson ,

Thanks for the bug report; it seems to issue is on the "view" page, and it's mistakenly editing the wrong data.

PG-3258 will fix this in the next maintenance release (April 17), but a prerelease is now available (inedo/proget:25.0.26-ci.6) if you'd like to try it.

-- Dean

@rcpa0 thanks for letting us know; we'll try to fix this next time we make some changes to pgutil it should only print "Version is not a valid semantic version." or something

Hi @geraldizo_0690 , unfortunately we didn't get a chance to review this for the last maintenance release, but it'll be in the next one (April 17) via PG-3257. It's also available via prerelease if you'd like (inedo/proget:25.0.26-ci.5)

-- Dean

Hi @davi-morris_9177 ,

I'm afraid this behavior is expected because kotlin-stdlib-2.3.20.jar is not in the downloaded index file. There's is no file-listing API, which means there's no way to know what should be there otherwise.

The Maven client downloads "blindly downloads" some files, and "silently accepts" a 404 for other files. When it's downloaded (cached), then ProGet knows about it. So, you really need to download the artifacts first if you want to make a curated feed I'm afraid.

-- Dean

Hi @certificatemanager_4002 ,

Check out our Licenses for Non-production / Testing Environments for the full details.

But if its a short-term migration testing scenario, then using an existing or trial key is fine. For a long-term environment, a separate license is required.

-- Dean