@rhessinger Please find the below screenshots. [image: 1789501938257-640b9488-7ebc-4053-aee4-18de22211944-image.jpeg] [image: 1789502035022-8e57279b-b1ca-448c-a348-a789b79ed8bc-image.jpeg] [image: 1789502057998-4ab7ab52-bd38-4f76-914b-05d08cc70e38-image.jpeg] [image: 1789502081615-2b848683-cffb-4dd4-bd7f-90511c0174d8-image.jpeg] [image: 1789502121741-28fba1e9-f687-40a7-a388-68628fc200e1-image.jpeg]

@rhessinger, Thanks for the detailed answer — that's helpful context, and to confirm: yes, by "bare username" we meant aduser1 (not aduser1@ourtest.local). We applied everything you suggested on the V5 directory: General tab: Domain = progetpoc.local, User name = Administrator, Password = (re-entered, confirmed saved) Connection tab: Domain controller host = 172.17.0.1, progetpoc.local (comma-separated, IP first, DNS name second) Advanced tab: NETBIOS name mapping = PROGETPOC=progetpoc.local Used the Test User Directories tool as suggested (User Directory: "AD Test V5", Test Type: "Login with user name and password", User name: aduser1, Password: matching what we set for that account). Result: Error: Connect Error [Debug] Search string is "aduser1"... We also checked our domain controller's own connection log during the test — it shows zero incoming connections, meaning ProGet isn't even reaching the network for this attempt. That suggests the failure is happening locally (e.g. during config/host parsing) rather than a real connectivity or credentials problem. Our leading suspicion is the "Domain controller host" field's expected format — we entered both values as a single comma-separated string (172.17.0.1, progetpoc.local). Is that the correct syntax, or does that field expect one value per line, a different separator, or only a single value with something else supplying the second lookup? Want to make sure we're not just malforming that field. Happy to send additional screenshots (any specific tab/dialog) if that helps narrow it down further.

@atripp, you recommend moving to "a modern, more secure technology." Is OIDC on ProGet's roadmap for feed authentication? Because today WIA is the only passwordless option for secured access in Proget -- the alternative is static, long-lived API keys -- and SAML does not help here, since it requires an interactive browser login and so cannot authenticate automated CI/CD pipelines.

Hi @sai.pabbareddy, For case 1, there is a cash of the users permissions for a short while (~5 minutes). You can force a cache reset on Administration -> Manage security -> Tasks/Permissions page, hover over Test Privileges, and then click Clear Cache. That will force the operation to take effect immediately. This is most likely happening because the bad user was already logged in prior to the change of permissions. For case 2, that same cache from case 1 looks like it also affects this as well and the clear cache button should also fix this. Looking at the code, it looks like there was a regression that removed the user directory cache clearing, but left in the user privleges cache clearing. I added a ticket, PG-3374, to fix these and it will be released in ProGet 2026.11. Thanks, Rich

Alana, Thanks for the clarification on CVE-2025-26646/Category 1 — that answered our question completely. Following up with two more things we ran into during the same Enterprise trial evaluation, since we're trying to understand whether these are also intentional design choices or worth reporting as bugs. Severity rating disagreement vs. NVD System.Drawing.Common 4.5.0 → CVE-2021-24112. When first flagged in our instance, ProGet rated this "Moderate". NVD (and Trivy, which we currently run alongside our existing pipeline) rate the same CVE "Critical". Is ProGet's risk rating here based on an independent assessment (similar to the Category-1 reasoning you gave for CVE-2025-26646), or is it meant to track NVD's CVSS score directly and this looks like a data/sync issue? If it's an independent assessment, is there somewhere we can see the reasoning behind it, the way PGV-2535204's Category-1 write-up explained the reasoning for that one? Client-facing vulnerability warning doesn't seem to update in real time We changed the assessment on a specific vulnerability four times in a row (Contain → Monitor → Contain → Monitor), and re-ran a fully cache-cleared dotnet restore after each change. The NU1902 warning shown to the NuGet client did not change to reflect any of those updates — it stayed the same throughout. Separately, we confirmed that the actual blocking behavior (packages failing to download once assessed Noncompliant, withAllowNoncompliantDownloads=false) does react immediately/in real time to the same assessment changes. So the disconnect seems specific to the advisory/warning channel, not the enforcement channel. Is the client-facing NU1902 advisory feed generated on a schedule (e.g., alongside the daily vulnerability database sync) rather than reflecting live assessment state? If so, is there a way to force/trigger a regeneration, or a recommended interval to expect it to catch up on its own? Context: we're doing a structured Enterprise trial evaluation and documenting exactly this kind of behavior so we can give an accurate internal recommendation — appreciate you taking the time on the first question, it directly changed a conclusion in our write-up. Thanks, Sai

Hi @amy.j , I don't think the API has changed, but I suspect it has something to do with multi-file packages, and the way that the aggregate result is presented. But I'd like to confirm that. Can you run the following script using the package you're looking at, and share the resulting output? import requests import os BASE_URL = "https://proget.example.com" API_KEY = os.environ.get("PROGET_API_KEY") FEED = "pypi-proxy-test" package = "charset_normalizer" version = "3.5.1" headers = { "X-ApiKey": API_KEY } metadata_response = requests.get( f"{BASE_URL}/api/packages/{FEED}/metadata?name={package}&version={version}", headers=headers, ) print(metadata_response.json()) for artifact in metadata_response.json()["artifacts"]: print(artifact["qualifier"]) response = requests.post( f"{BASE_URL}/api/packages/{FEED}/audit?name={package}&version={version}&qualifier={artifact['qualifier']}", headers=headers, ) print(response.json()) Thanks, Alana

Crazy ... and this issue is still open https://gitlab.com/gitlab-org/gitlab/-/work_items/588736 That way the combination is not usable... I really wonder how the build in dotnet nuget tooling is working with the group feed.

Hey there, very nice to see this topic discussed here. Just my two cents: I'm running Grafana Alloy as a sidecar container, exporting the ProGet console output and the Nginx logs to a central Grafana instance. This gives me some visibility into how the application is running. Exporting the Logs from the database table via OpenTelemetry to some SIEM would be very nice too.

@atripp award for fastest forum response goes to you yep that seems to have solved it :) simple enough ;) Thanks! Maybe it would be an idea to highlight or add a little orange "stalled" badge on the ones in the list that causes the warning? Just a nice to have. Cheers Carl

Hi @certificatemanager_4002 , The API is a bit harder to use than just pgutil, so I'd suggest to use pgutil instead and it's easy to make a simple mistake like encoding something incorrectly. Without studying your code and having direct access to your ProGet instance, I cannot tell you what the issue is. But, since pgutil works we know the API is fine; here is the code that pgutil uses to delete the user: https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L744 would suggest to use a local proxy tool like fiddler classic, proxyamn, postman, etc., that can capture and analyze local HTTP traffic so you can see the difference between what your code is doing and what pgutil is doing. Thanks, Alana

Hi @gdivis, Thank you, I can confirm that the case with a partially downloaded file now returns the correct Content-Range header as expected. However, when a file is fully downloaded, it still returns an Invalid Content-Range header: $ wget --server-response --continue --tries 1 https://<PROGET_URL>/endpoints/assets/content/example_file ... HTTP/1.1 206 Partial Content Content-Range: bytes: 1000-999/1000 ... Giving up. I know this is a bit of an edge case, as usually you don't try to continue downloading a file that is already fully downloaded. However it does happen in specific cases with bitbake so it would be good to get this case fixed as well. Thanks, Joris

Hi @rob , When using the the subject name, the X509NameType.SimpleName is extracted and compared. Here's the specific logic: x509Store.Certificates.Where(c => c.GetNameInfo(X509NameType.SimpleName, false).Equals(config.Subject, StringComparison.OrdinalIgnoreCase)).OrderByDescending(c => c.NotAfter).FirstOrDefault() So if the "wrong" Server1 is being selected, I'm guessing it shares the same simple name. In scenarios like this, we recommend renaming the certificate (e.g. ProGetSsl), using a file, or the thumbprint. Thanks, Alana

Hi @gdivis Thank you so much for your support. Best regards

Hi @nils-nilsson, We've investigated and this is definitely a bug in the feed management API. Unfortunately that API is pretty rough, and this is not at all the trivial fix it ought to be. I've logged the issue as PG-3369 and scheduled it for ProGet 2026.12, which is the release after next, currently targeted for Oct 2. -Greg

Hi @federico.conoscenti , Universal Package do support arbitrary metadata in the manifest file, and ProGet will display that on the UI. It's technically possible to add arbitrary metadata to other package files as well, although obviously ProGet could never know about or display that. However this metadata is not intended for searching or indexing. ProGet does not support "arbitrary, server-side metadata" for any package types. In other words, you cannot simply "tag" or "annotate" otherwise packages after they've been added to ProGet. This is intentional and by design, as it keeps the metadata contained to the manifest file (which is stored within the package file itself), which effectively makes it "cryptographically sealed" and cannot be tampered with. So, as you migrate from Artifactory, you'll need to change your workflows to support a more modern, package mindset. In case you haven't seen it already, we have a Migrating from Artifactory to ProGet Guide that you may find helpful. Best, Alana

Thanks for the feedback @lukas.christel_6718 In the year and a half since my last rant, it doesn't look like the state of OCI Registries has changed much. I haven't been seeing any real adoption beyond some quirky or niche uses cases like Flux, due to all the reasons I mentioned earlier. It's a terrible repository format. That said, S3 (or the API I should say) seems to have become a kind of standard, and we're seeing a lot of users switch to S3 alternatives that use the S3 API: https://blog.inedo.com/proget/s3-alternatives For example, we've switched to Wasabi and have saved a ton in egress fees. You should probably have some kind of S3-esque thing in your organization already -- and if not, you should set one up. ProGet Asset Directories are convenient, but they aren't designed to solve the same problems as cloud-like storage. Cheers, Alex