Hi @andreas.unverdorben_1551 ,

Just as an FYI, I submitted two pull requests for this:

• https://github.com/github/advisory-database/pull/8689
• https://github.com/github/advisory-database/pull/8690

Thanks,
Alana

@joshuagilman_1054 I don't really know PowerShell myself (today I learned you can do classes )... but behind-the-scenes it's .NET, and that means we can use nullable value types.

I tried [int?] (nullable shortcut syntax) and [Nullable<int>] (generics shortcut syntax) but PowerShell isn't so happy with either. So the long way it is...

[System.Nullable``1[[System.Int32]]] $myInt = 0
echo "myInt is $myInt "
$myInt = $null
echo "myInt is $myInt "
$myInt = 1000
echo "myInt is $myInt "

That should do the trick for you, and is close to our JSON Model anyways.

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

@Stephen-Schaff said in API to apply an Alternate Tag to Docker Container Image:

Here is the PowerShell function that does both the promotion and the tagging (incase anyone ever needs something like this). Kind of a "do it yourself" repackaging. (Might be nice to have the Repackaging API support Docker container images someday).

Thanks for sharing this, I've added it to our Semantic Versioning for Containers docs page, I hope that's okay :)

And yes I agree, it woudl be nice to make this an easier API call

Hi @m-lee_3921 ,

Thanks for the heads-up; we'll get this fixed via PG-3059 in the next maintenance release (scheduled for later today).

And you're right -- its basically the same issue. SQL Server silently truncates string values whereas PostgreSQL does not, hence these errors.

We decided to not auto-truncate, since it's better to know about these cases than not. In this case, it's a IPv6 address that was longer than the 20-character limit. We plan to refactor API key logging at some point, so we'll just continue to truncate v6 IPs.

Thanks,
Alana

Hi @carl-westman_8110 ,

The error message means that the database wasn't updated as per normal during the start-up process. It's hard to guess why, as we have special handling for that.

It's likely that restarting the service would have fixed it, but downgrading and then upgrading would also force an upgrade as well. Unfortunately it's hard to say at this point.

Upgrading to 2025.10 should be fine.

Thanks,
Alana

Hi @amy.j ,

This sounds like it's related to PG-3356, which is targeted for this week's maintenance release.

Can you upgrade to 2026.10 (once released) and give it a sot after that?

Thanks,
Alana

Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Hello; you'll need to change the BaseUrl in advanced settings so that ProGet can construct an absolute URL when needed (certain NuGet fields, etc). I've updated the docs to reflect this.

We've got some major container improvements coming in ProGet 5.3, and will revamp our product; hopefully we'll be able to present this pretty soon!

I think, once you see what we have planned, you'll want to change/improve your workflows to simplify things, and this may not even be necessary... anyways, stay tuned.

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