Hi @sai.pabbareddy, Let me run some other tests. It could be related to the LDAP escaping that is happening, but that would be highly unlikely as we have many other users currently using the OpenLDAP/Generic LDAP user directory. I think the more peculiar thing is that when you hard coded the uid, the logs didn't show ?uid=, but with the %s it did. That makes me think that it does not like the value that is being passed in. Does the group search have the same issue and log message? Thanks, Rich

@rhessinger , Ran the test you suggested — good news, this narrows it down cleanly. "Search for groups" (group name Domain Users): succeeded, found 1 group, no referral exception. "Load user by user name" (aduser1, group Domain Users): also succeeded cleanly — "User aduser1 found," then a clean "Is not member of Domain Users" result (makes sense — Domain Users is aduser1's primary group via primaryGroupID, which typically doesn't show up in memberOf on AD, so that's expected AD behavior, not an error). No referral exception in either test. So basic group lookup and direct membership checks are both fine — the referral really does seem isolated to whatever recursive/transitive resolution happens specifically in the real permission-authorization path (matching your theory about the magic OID for nested group search), not group operations in general. Given referral-chasing being disabled by default on the Linux build is the underlying mechanism, that's useful to know regardless of the Samba-4-specific trigger — it's the kind of thing that could surface against a real multi-domain Windows AD forest too, not just our test setup. We'll note that as a known limitation of the Docker/Linux deployment specifically rather than something to expect fixed here. Appreciate you digging into this as much as you have — this has been a genuinely useful back-and-forth for us. Thanks, Sai

@rhessinger Thanks.

@atripp , Thanks for the info.

@atripp, Went back through your docs and our own notes trying to pin down a specific page, and honestly — we can't find one. The closest we got was a page showing how to create a Specified License Rule (e.g., setting GPL-3.0 to noncompliant), but every example there is clearly a user-configured policy, not a factory default. We think our original impression was a general one from early research rather than something we can point to a specific article for, so no need to go hunting on our end — sounds like it was just an assumption on our part rather than something your docs actually claimed. Good to have it confirmed either way: no default license rule ships out of the box, and creating one (GPL or otherwise) is expected as part of setting up a feed. We'll document it that way. Thanks, Sai

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, [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 @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