Hi @joris-guex, Thanks for sending an example over. It looks like this is related to an issue in the libssh2-sys's manifest. I have created a ticket, PG-3321, to handle these issues better. We are expecting to have a fix out within the couple of maintenance releases of ProGet 2026. Thanks, Rich

Hi @atripp, We have now updated to ProGet 2026.3 and can confirm this is now working as expected. Thank you for your prompt help.

Perfect, thanks Alana :)

Hi @_moep_ , So there are quite a few "moving pieces" here. Vulnerability -> Assessment -> Compliance -> Build Issue Vulnerabilities & Assessments First and foremost, when you navigate to qs@0.6.6 in the ProGet UI, you should see several vulnerabilities listed, such PGV-2287703. So, the "identification" is there as a result of the offline version of that database being included with ProGet. But, ProGet is all about reducing noise while helping elevate real risks - and most vulnerabilities are theoretical, have no real-world exploits, would require a dedicated attacker, and would result tin no real damage. A "Denial of Service from Prototype Pollution" is great example of such a vulnerability. The risks and problems introduced by reactively upgrading every dependency far exceed any benefits -- moreover, it "de-sensitizes" everyone to real security risks. The idea of "when everything is severe nothing is" is the same as "when everything is a priority, nothing is". That's where Assessment comes in. In ProGet 2025 and earlier, a vulnerability is generally as "assessed" Ignored, Warn, or Blocked. PGV-2287703 will be assessed as Warn by default. **NOTE this will be changing in ProGet 2025. ** Policies & Compliance Next, there's the question of Compliance; the vulnerability assessment (among other things, like license, deprecation status, etc) will determines whether or not a package is Compliant, Noncompliant, or Warn. Compliance rules are configured in policies. In ProGet 2025, by default, the "Warn" Assessment will not make a package Noncompliant. Just Warn. Builds & Issues A Build is considered Noncompliant if any of the packages are Noncompliant. A Noncomplaint build should be blocked from deploying to production. This is where Issues come in: an issue may be created when a build is analyzed (try it out by clicking [analyze] in the UI) for a Noncompliant package. The purpose of these Issues are to effectively "override" the compliance status on a single package. They are not informational; if you want a list of packages, vulnerabilities, licenses, just use pgutil builds audit to get that listing. Long story short, I'd decide on a process you'd want to use before even considering web hooks for all this. Also note that this mostly requires a paid license, so you may not even be getting functionality if you're on a free version hope that helps, Alana

@rhessinger Thank you Rich - will install it once released and confirm it is fixed.

Hi @paul-moors_5682 , We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow. One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice. Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical. Cheers, Alex

To follow up, we ended up being able to get everything working using userPrincipalName for user identity by switching to the OpenLDAP/GenericLDAP connector. The remaining issue I was seeing - unexpected failed group lookup in the "Test User Directories/Load user by user name" test - appears to have been caused by a quirk in the connector. In this particular test for this particular connector, group names are case sensitive. In the other tests for this connector, and in all the tests in the AD connector, group name case is ignored. This does not seem to have any repercussions in actual use, but it led us a merry dance for a while.

@stevedennis I understand. Thank you for your fast Reply and explanation. I see why it can be troublesome and actually go against Proget's core functionality to allow what I was talking about. Thanks! Regards.

@stevedennis I see, Thank you for your fast reply. Regards.

Thanks for the comprehensive response - which was very helpful. Closing the loop, we've elected for the short term to run up a parallel aptly server to manage our existing apt snapshots, but in the longer term we'll revisit how we use snapshots at all and very likely will switch our process to use upstream provided snapshots.

Hi @koksime-yap_5909 , As long as the cluster can access the internet (our activation server), the license key should be auto-activated without noticing. This document explains the activation process a little further: https://docs.inedo.com/docs/myinedo/activating-a-license-key Help that helps, Alana

Hi @koksime-yap_5909 , I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc. The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help. This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first. Hope that helps, let us know if you have any other questions! Thanks, Steve

Hi @koksime-yap_5909, The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as. On ProGet 2025, the command is proget or proget.exe We should update the docs for sure Thanks, Steve

Hi @koksime-yap_5909 , Not necessarily - it really depends on the API query. If the query is like "give me a list of all versions of MyPackage", then ProGet will need to aggregate local packages and connector packages to produce that list. If the query is "give me the metadata for MyPackage-1.3.1", then the first source that returns a result is used. In practice, NuGet asks for "all versions" a lot. So you'll get a lot of queries. Thanks, Alana

Hi @koksime-yap_5909 , Docker registry import from Sona, JFrog, and other ProGEt instances is coming soon via PG-3128 - we anticipate that in the next maintenance release. As for Assets, I'm afraid we don't have any support for that planned in the near future - it's relatively easy to write a script that "extracts" them - if you could extract it to a ProGet drop path, then they'll be imported that way. https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import-with-droppath -- Dean

Hi @koksime-yap_5909, No; when you use LDAP, then you need to manage the LDAP users' groups in your directory. Here is a recent discussion on the topic: https://forums.inedo.com/topic/5471/feature-suggestion-allow-ad-users-to-be-added-to-built-in-groups Thanks, Steve

Hi @koksime-yap_5909 , This is the "Feed Overview" page and the URL that you need: [image: 1753972503072-a47685c2-9018-4f39-a0f9-56fccb468fc1-image.png] Thanks, Steve

Hi @koksime-yap_5909 , That's just a "suggestion box" in the UI - you can just type in whatever you'd like. But in general you shouldn't upload files via the UI, but using maven. Thanks, Steve

Hi @koksime-yap_5909 , This is a known issue and will be fixed via PG-3063 in teh next maintenance release, shipping later today. Thanks, Steve