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

SQL Server is super fun! So the account you initially installed ProGet with in Inedo Hub will have permissions in SSMS to modify permissions for the SQL instance. This is because Proget installs SQL for you if you don't already have it installed. If you have the credentials the Proget service used to use, log in to SSMS with those credentials, then create the SQL Server login for the NetworkService account following @atripp's guidance above. Then, when you start the ProGet service, it should "see" the database.

Got this on a NPM feed, which has a connector to *npm-registry.npmjs.org. Recently upgraded to 25.23.11 An error occurred processing a POST request to http://packagemanager.REDACTED/npm/NPM-Source/-/npm/v1/security/advisories/bulk: '0x00' is an invalid start of a property name. Expected a '"'. LineNumber: 0 | BytePositionInLine: 1. System.Text.Json.JsonReaderException: '0x00' is an invalid start of a property name. Expected a '"'. LineNumber: 0 | BytePositionInLine: 1. at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes) at System.Text.Json.Utf8JsonReader.ReadSingleSegment() at System.Text.Json.JsonDocument.Parse(ReadOnlySpan`1 utf8JsonSpan, JsonReaderOptions readerOptions, MetadataDb& database, StackRowStack& stack) at System.Text.Json.JsonDocument.Parse(ReadOnlyMemory`1 utf8Json, JsonReaderOptions readerOptions, Byte[] extraRentedArrayPoolBytes, PooledByteBufferWriter extraPooledByteBufferWriter) at System.Text.Json.JsonDocument.Parse(Stream utf8Json, JsonDocumentOptions options) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmAuditHandler.HandleBulkAdvisory(AhHttpContext context, NpmFeed feed) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmAuditHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl) at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context) ::Web Error on 19.03.2026 19:52:44::

Hi @gbeckett, Glad to hear it is working for you! Please let us know if you run into any other issues. Thanks, Rich

Hi @stevedennis , hi @geraldizo_0690 , sorry for the late reply, it was indeed a timesync issue. Thanks, Matthias

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

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.

Hi @certificatemanager_4002 , From the cybersecurity perspective, it's fine to leave it as root since the core process is run by the non-root user postgres inside of the container. You're never exposing a network service while the containerized process has root privileges. Here is more information on this if you're curious: https://stackoverflow.com/questions/73672857/how-to-run-postgres-in-docker-as-non-root-user As you can see in that link, it's technically possible to configure as non-root, but it requires more effort and doesn't really get you any benefit. As for load-testing and restarting, it really depends on the hardware and similar factors. Keep in mind that InedoDB is simply the postgresql container image with some minor configuration tweaks/changes. So any question you ask about InedoDB you can really ask about postgresql as well. As for using an external PostgreSQL server, the only information we have at this time is in the link I sent you before. You really need to be an expert on PostgreSQL if you wish to run your own server. Thanks, Alana

It looks like someone (at IP 10.2.12.133) has configured the wrong URL in Visual Studio or something. They are trying to access the NuGet API via the wrong URL (note the /feeds vs /nuget at the base url). Cheers, Alana

As I understand it, having a user with dbo-role is not sufficient(according to stackexchange). Since our user is role dbo, but not set as owner on the database, it does not work. Anyway, this is not a problem for us since we do run this manually :)

Ay thank you so much. Yes. It's an air-gapped network. I found the files and have made a docker volume back to the machine.

Ah, fantastic - thank you. I'll keep an eye out for it!

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

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

Hi, Fashionably late here, but what @atripp said is accurate. Chocolatey's moderation process on the Chocolatey Community Repository is a completely separate process to the vulnerability management features available in ProGet. Our moderation process was put in place shortly after the Chocolatey Community Repository went live 15 years ago, and some packages were added to the feed and haven't received updates since then. While our moderation process is really good, and we've never seen malicious content make it to approved status, you should always detonate-test a package in your own environment before promoting it to a production repository.

Hi @Valentijn, We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available. Thanks, Rich

@dean-houston By way of follow up, unfortunately the verbose output of an apt update against the jenkins repo provided exactly 0 clarity. apt update -o Debug::Acquire::http=true Ign:1 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:2 https://pkg.jenkins.io/debian-stable binary/ Release Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. I appreciate the help in trying to make this work, but I am going to punt on this and just grant the specific server access directly to pkg.jenkins.io.

Hello, Great news! Thanks, Scott