Hi @seanl_4808 , Like SAML, OIDC is not intended for developer/CLI tools, but desktop-based applications. I'm not aware of any client-tooling that supports or plans to support OIDC, so there's no sense in having a sever-based tool supported OIDC. API keys are considered the modern/secure solution. The reason that WIA/OIDC is considered less secure comes down to reducing the attack surface. A rouge user or process would be able to do very little with a limited-access ProGet API key, compared with domain credentials. Thanks, Alana

Hi @sai.pabbareddy , A 500 is an system error and would be logged under Admin > Diagnostic Center. It's possible there was system overload, network issues, who knows. I wouldn't worry about it. A 403 is a permission error that would be caused by configuration. It sounds like you resolved it by changing/modifying configuration, waiting for a cache to clear, etc. Thanks, Alana

Hi @sai.pabbareddy , There is no rule, but I believe admins are encouraged to create one as part of the "onboarding" process when creating feeds, at some point. Can you point to the documentation that shows that? We will clarify the documentation. Thanks, Alana

Hi @sai.pabbareddy , This is by design; download blocking is not supported on Docker feeds because it creates a very poor deployment experience, in particular with "fat manifest" images. There is simply no way to communicate to the end-user (typically a devops/release engineer) that an image is blocked, and they just end up getting random and indecipherable errors from the client. This happens at deploy time, so it causes huge panic. Blocker tickets get opened. Everyone "blames" the tools and no one understands why. Keep in mind that Docker containers are constantly deployed, so you jus tend up with random production deploy failures from "yet another" overrated vulnerability that just happens to pop-in the system. Compare this to packages, which are consumed at build-time only and "blocking" only causes a poor developer experience (rarely production failures). Please use pgutil containers audit instead: https://docs.inedo.com/docs/proget/api/containers/audit-image Thanks, Alana

Hi @sai.pabbareddy, [1] Here is some more information on PVRS vs CVSS: https://guides.inedo.com/vulnerability-management/cvss-pvrs/ Long story short, PVRS is designed for OSS dependencies and analyzes risk differently, in particular taking into account the custom risk profile you enter in ProGet (under Policies). [2] The NU1902 advisory comes from a vulnerability.base.json file that is cached both on the client end and ProGet end; you need to clear the http caches on NuGet (which you did), and ProGet will invalidate it about once an hour. You can force invalidation by restarting the service (Admin > Service) or manually assessing vulnerabilities (Admin > Vulnerabilities > Reassess), but that should only appear for test purposes. In a normal workflow the client will aggressively cache this file, and there's no real harm in having outdated information when following our recommended workflows. On that note.... we do NOT recommend you block downloads. It will actually lower your organization's security posture, not improve it. Please review this to learn how to "contain" properly: https://guides.inedo.com/vulnerability-management/containment/ Thank you, Alana

Hi @sai.pabbareddy, You will have to also set the Group Search Base as well. Can you test that and let me know if anything changes? Also, what OpenLDAP server are you using to run these test with? Thanks, Rich

Hi @sai.pabbareddy, We will be releasing ProGet 2026.11 this Friday, September 15th. Thanks, Rich

Hi @sai.pabbareddy, The Domain controller host field does not accept a comma separated list. I meant first try setting that to the IP address of your domain controller and then test the connection. Then if that works, then change the value to the DNS name of the Domain Controller (just progetpoc.local) and test it again. That just helps to verify if there is a DNS lookup issue. Thanks, Rich

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