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 :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @it_9582 ,

What version of ProGet are you using? There was a recent regression (PG-3204) that was fixed in ProGet 2025.19 with regards to symbol server. S hopefully upgrading will fix the issue.

Cheers,
Alana

Hi @jeff-williams_1864 ,

I'm not quite sure why nuget.org would report using a self-singed certificate? That seems off, but it sounds like you're doing "something" with regards to certificates that I don't quite understand :)

On that note, the /usr/local/share/ca-certificates volume store the certificates to be included in the container's certificate authority, which is used when connecting to a server with self-signed certificates: https://docs.inedo.com/docs/installation/linux/docker-guide#supported-volumes

Hope that helps,

Alana

hi @certificatemanager_4002 ,

The 500 is occurring on /health because licenseStatus=Error and the software is basically unusable until you correct the license issue.

You would see a similar "blocking" error in the ProGet UI as well - so just check that, and once you correct the license error, the health check will return to normal..

Thanks,
Alana

Hi @certificatemanager_4002 ,

The license key is set via the UI, so you can browse/access the service as per normal. Then, you will prompted to do that right away when there is no key or it expired: https://docs.inedo.com/docs/myinedo/activating-a-license-key

Thanks,
Alana

Hi @svc-4x9p2a_6341 ,

First and foremost, Chocolatey does not incorporate "Vulnerabilities" (i.e. centrally aggregated reports of vendor-reported weaknesses in software) into the package ecosystem. This is just not something that's a part of the Windows ecosystem as a whole, unlike the Linux ecosystem (e.g. Ubuntu OVALs).

Chocolatey does, however, perform automated malware/virus scanning on packages. That's a totally different thing... please read our How Virus Scanning in Chocolatey Works article to learn more.

From a technical standpoint, ProGet will use (abuse?) the vulnerability subsystem to treat "flagged" packages as vulnerable. This was a "quick and dirty" way for us to experiment with exposing this data through ProGet without having to build an entirely new subsystem just for Chocolatey packages.

As for crystalreports2008runtime, it did not fail the virus/malware checking, so it's not going to be seen as "vulnerable" by ProGet. Instead, it hasn't been "validated" by Chocolatey's automated system. That's a different feature altogether (i.e. unrelated to virus checking) - and that ancient crystal reports package long predates the moderation feature in Chocolatey I believe.

In any case, ProGet does not expose nor allow users to "filter" on this validation status, and it's highly unlikely such a capability would add much value to users - especially considering no one has asked for it, and the cost of developing an entirely new, Chocolatey-only feature is nontrivial.

The reason is that everyone internalizes their packages; see Why You Should Privatize and Internalize your Chocolatey Packages
to learn more

Hope that helps, maybe @steviecoaster can assist more.

Cheers,
Alana

Hi @svc-4x9p2a_6341 ,

First and foremost, Chocolatey does not incorporate "Vulnerabilities" (i.e. centrally aggregated reports of vendor-reported weaknesses in software) into the package ecosystem. This is just not something that's a part of the Windows ecosystem as a whole, unlike the Linux ecosystem (e.g. Ubuntu OVALs).

Chocolatey does, however, perform automated malware/virus scanning on packages. That's a totally different thing... please read our How Virus Scanning in Chocolatey Works article to learn more.

From a technical standpoint, ProGet will use (abuse?) the vulnerability subsystem to treat "flagged" packages as vulnerable. This was a "quick and dirty" way for us to experiment with exposing this data through ProGet without having to build an entirely new subsystem just for Chocolatey packages.

As for crystalreports2008runtime, it did not fail the virus/malware checking, so it's not going to be seen as "vulnerable" by ProGet. Instead, it hasn't been "validated" by Chocolatey's automated system. That's a different feature altogether (i.e. unrelated to virus checking) - and that ancient crystal reports package long predates the moderation feature in Chocolatey I believe.

In any case, ProGet does not expose nor allow users to "filter" on this validation status, and it's highly unlikely such a capability would add much value to users - especially considering no one has asked for it, and the cost of developing an entirely new, Chocolatey-only feature is nontrivial.

The reason is that everyone internalizes their packages; see Why You Should Privatize and Internalize your Chocolatey Packages
to learn more

Hope that helps, maybe @steviecoaster can assist more.

Cheers,
Alana

hi @tyler_5201,

For a case like this, I'd recommend using a custom metadata field like _vendorVersion or something like that? Of course, that's going to be relatively easy.

The hart part is to "map" the vendor numbers to a SemVer. I would look at the data, and decide how you want to "pack" them into three segments.

2024.3.201 might work, assuming there are less than 100 revisions per service pack. Or maybe 2024.302.1. The number is really just for you, so whatever makes sense to you :)

Cheers,
Alana

Hi @scusson_9923 ,

One idea ... how about a try/catch block?

It's not great.... but the catch will indicate the file doesn't exist.

Just a thought...

Thanks,
Alana

Hi @Sigve-opedal_6476 , we're currently investigating and will let you know more later this week

Hi @davi-morris_9177 ,

Unfortunately, the source data for these particular vulnerabilities specify invalid version numbers. A valid Maven version is a 5-part number consisting of 1-3 integer segments (separated by a .), an optional build number (prefixed with a -), and then an optional qualifier (another -). Following these rules, 2.9.10.8, is invalid.

Valid versions are semantically sorted, where as invalid versions are alphabetically sorted -- which is what's causing the big headache here, since "2.21.1" < "2.9.10.8" when you sort alphabetically.

At this time, we don't have any means to "override / bypass" source data, and rewriting/updating our Maven version parsing for just a small corner case (i.e. these old/irrelevant vulnerabilities in particular) doesn't seem worthwhile.

As such, for the time being, your best solution is just to "Ignore" these vulnerabilities via an assessment. They are totally irrelevant now, not just because they refer to ancient versions, but there is simply no realistic real-world exploit path: https://cowtowncoder.medium.com/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

FYI - for ProGet 2026, we are working on a lot of improvements in vulnerability management that will reduce the noise of these non-exploitable vulnerabilities so teams can address actual risk and focus on delivering value instead of constant patching.

Thanks,
Alana