Hi @federico.conoscenti ,

Self-connectors won't work in Docker as repositories are already rooted and accessible across all feeds. It's just a quirk of the Docker API really.

The Docker API specifies that the index is located at /v2/_catalog, and as you can see, there's no indication of "feed". For example: https://proget.inedo.com/v2/_catalog

A "feed" is just the first portion of the repositories namespace.

Thanks,
Alana

Hi @amy.j ,

Without a reliable publish date, there's no reasonable way to rely on an automated compliance rule that relies on the publish date.

I would recommend developing a Maven-specific approach, since this feed type is so limited. You've probably noticed it already, but license detection is also not very reliable. But, I wouldn't worry too much about it. Keep in mind:

• the Java ecosystem seems to publish much less frequently than JavaScript
• there are fewer transient dependencies in Java
• version ranges tend to be less popular and much more conservative

Also there seems to be an issue with pulling in certain jar files, eg, when org.springframework:spring-webflux 6.2.19 is promoted no jar file is listed - so cannot be consumed. This has happened for a few packages.

This is probably related to that unreliable Maven Index file.

The Maven API does not support "file listing", so there's no automated way to know what artifacts are contained within a particular release. You just "kinda know" by reading the project's release notes, etc.

Early on, we just "assumed" there would always a .jar file, but I guess that's not the case because there are .war and .ear files too. We also considered parsing the web-based file listing page (e.g. spring-webflux/6.2.19, but a lot of repositories don't provide a listing.

We're open to ideas, but it's just an unfortunately limited ecosystem.

Thanks,
Alana

Hi @sai.pabbareddy ,

Those are both "packages" that contain the same kind of license (ProGet Enterprise).

A single ProGet Enterprise license will allow you to configure a ProGet instance as a HA/cluster.

• "Enterprise Essentials" contains ONE license of ProGet Enterprise and no services
• "Enterprise Complete" contains TWO licenses of ProGet Enterprise plus services

Organizations will often get two licenses of ProGet Enterprise to create two different environments (one Production, one DR/Testing/Training). Hope that helps clarify :)

Thanks,
Alana

Hi @amy.j ,

This package is a bit weird in that (1) it uses a file-embedded licenses, (2) there are 172 contained files, and (3) some of those files don't follow standard naming conventions. When those things happen, I think we get results like this.

The easiest way to work-around this is to just assign a license directly to the package using the Purl (i.e. pkg:pypi/charset_normalizer@3.5.1). You can do that by editing the MIT license type.

Thanks,
Alana

Hi @amy.j ,

I'm afraid publish dates won't work reliably on Maven feeds.

A Maven repository does not contain server-side metadata like Download Count, Publish Date, Deprecated, etc., or even a search capability It's little more than web-based file system with maven-metadata.xml files that are generally maintained by the mvn client (e.g. it will always upload a new maven-metadata.xml file as part of a publish).

The Maven Index file (i.e. nexus-maven-repository-index.gz) attempted to solve the lack of metadata, but it's quite problematic these days (it's like 20-30GB at this point) and is generally disabled by default in most other products (e.g. Artifactory, Sona). On of the problems is that the file does not contain entries for all artifacts, including the .pom.

Publish date is part of the NuGet API, but old packages or some servers may not maintain. It's server-side metadata (like download count), and some basic repositories will just use default dates and 0.

Thanks,
Alana

Hi @jw ,

Can you share us a copy of your database bacakup or export?

I created a ticket that will allow you to upload this: EDO-13159

Once we have that, wecan investigate this further.

Thanks,
Alana

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

Hi @sai.pabbareddy ,

I'm not really sure what question you're asking?

CVE-2025-26646 has been in Inedo's database as PGV-2535204 since May 13, 2025.

However, under the default risk profile in ProGet, we rate this a Category 1 since there is effectively no risk posed by this vulnerability. It requires a malicious inside actor with access to modify the source code -- which is not a realistic threat actor.

As such, ProGet will not not "spam" developers via the NuGet client with needless warnings. This is all by design.

You can learn more about that here: https://guides.inedo.com/vulnerability-management/categories/

Thanks,
Alana

Hi @carl.westman_8110 ,

It looks like several have, since the Next Run Time is in the past for several of them.

I would just hit the "Restart Service" button to resolve this.

Thanks,
Alana

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

Maybe you're attempting to delete a principal that's not a user, such as a group or Anonymous or something.

In any case, the API uses the exact same code as the UI; I'll share it:

case "delete":
    EnsureMethod(context, "POST", "DELETE");
    var userName = context.Request.QueryString["user"];
    if (string.IsNullOrEmpty(userName))
        throw new HttpException(400, "Expected user query argument.");
    DB.Users_DeleteUser(userName);
    break;

Here is the UI code for the button click on the /administration/security/users/delete-user?userName=asdfasdf page:

var btnDelete = new PostBackButtonLink(
    "Yes, Delete User",
    () =>
    {
        DB.Users_DeleteUser(this.UserName);
        WebUserContext.ClearCache();
        this.CloseModalWindow(false);
    }
);

Your request might not be reaching the endpoint; I would attempt to do DELETE /api/security/users/delete?something=nothing to make sure you're getting a 400 error.

Hope that helps.
Alana

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

Hi @seanl_4808 ,

First and foremost, we recommend that you move away from Windows Integrated Authentication as Microsoft is discontinuing the technology and move to a modern, more secure technology. It's only going to be a matter of time before WIA stops working altogether due to bugs or removal of support by us or Microsoft.

That said, WIA is pretty limited as you can see. However, you can try configuring IIS as a reverse proxy that forwards https://hostname:443 to http/:*:8624; that may also make certificate management easier. We don't have a guide to set that up, however; I'v eonly heard of one customer who made it work somehow with WIA.

Thanks,
Alana

Hi @certificatemanager_4002 ,

My guess is there's some kind of typo with the username you're sending.

The name is not validated before attempting to delete, which means you can type in any string and a 200 will be returned.

If you don't send an arggument, you will get an error however.

I would also try using pgutil security users delete to see if that helps:
https://docs.inedo.com/docs/proget/api/security/users/delete

Thanks,
Alana