Hi @it_9582 ,

If I'm understanding correctly, the issue is that windbg is attempting to download the symbol with an ID of 0511335..., but the only symbol you're seeing in ProGet is 58544d5...?

Since this is for C++, this is the Windows/PortablePdb format. In that case, ProGet is using the built-in class called MetadataReader to parse this information. I mean it's possible there's a bug in there, but I think it's more likely that it's the wrong file getting uploaded or something to that effect.

As far as the URLS... I'm not sure what the correct one is, but windbg seems to try a whole bunch of URLS before it lands on the correct one in ProGet. But if you're seeing that 58544d5... symbol in ProGet, then it would be downloadable.

Thanks,
Alana

Hi @dev_7037 ,

We've actually just changed this and, in the upcoming maintenance release, you'll be able to specify - for the file name. When you do that, the query can be entered via stdin.

Cheers,
Alana

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

Hi @geraldizo_0690 ,

Nice find with the busybox image... that makes it a lot easier to test/debug on our end!!

We already have a ZST library in ProGet so, In theory, it shouldn't be that difficult to use that for layers like this. We'll add that via PG-3218 in an upcoming maintenance release -- currently targeting February 20.

Thanks,
Alana

Hi @geraldizo_0690 ,

Are you seeing any errors/messages logged like, Blob xxxxxxx is not a .tar.gz file; nothing to scan.? If you go to Admin > Executions, you may see some historic logs about Container scanning.

Thanks,
Alana

Hi @Sigve-opedal_6476 ,

Could you give some tips/guidance on how to repro the error? Ideally, it's something we can see only in ProGet :)

It's probably some quirk in how they implement things, but I wanted to make sure we're looking at the right things before starting.

Thanks,
Alana

Hi @scusson_9923 ,

That is an internal/web-only API url, so it wouldn't behave quite right outside a web browser.

I can't think of an easy way to accomplish what you're looking to do.... if you could share some of the bigger picture, maybe we can come up with a different approach / idea that would be easier to accomplish.

Thanks,
Alana

Hi @certificatemanager_4002 ,

I'm sorry but I'm not familiar enough with Kubernetes to help troubleshoot this issue.

All that I recognize here is the upgradedb command, which is documented here:
https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional

If you run that command from the command-line (on either linux or windows), things will written to the console. I wish I could tell you why you aren't seeing the messages.

Thanks,
Alana

Hi @phil-sutherland_3118 ,

This is not on a roadmap. Honestly we really don't really understand what a "snapshot" repository is or how they are used.

We surveyed some customers about it a while ago, and this summarizes what they said: repository snapshots are archaic; they made sense a long time ago, but Docker changed all that. It's so much simpler to use container images like FROM debian:buster-20230919. That's effectively our snapshot, and when we need to main old releases (which happens more often than I'd like), we just rebuild the image from that. The other big advantage is that build time is easily 10x faster if not more.

And then we saw that Debian also to maintains their own snapshots (https://snapshot.debian.org/), so we don't quite get how they are used outside of a handful of use cases (like a build process for a specialized appliance OS without Docker).

Anyway we're open to considering it.... but only two people (including you) have asked in the past several years, so there's no real interest... and we're not sure what they even do :)

That said, it's possible there's a way to accomplish something that has the same outcomes. For example:

• create a public aggregate feed (jammy-all) with multiple connectors to Debian, Ubuntu, NGINX, Elasticsearch, etc.
• create a release feed (jammy-20231101) that snapshots jammy-all

But we don't know enough to answer that :)

Thanks,
Alana

Hi @parthu-reddy ,

I'm not sure if there's a relation here, but perhaps. The "running out of disk space" is not surpsing if you're indexing mega-repositories like the public debian repos. They are gigabytes in size. Here's some more info about those:
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds

You definitely want to switch to Indexing Jobs when you connect to public repops.

This can be set at operating system level (it's the %ProgramData% special folder) or in ProGet under Admin > Advanced Settings > LocalStorage.

Anyway this is somethitng best brought up as a separate topic if you have follow-ups (if you don't mind), I'd hate to pollute this thread with debian/indexing questions :)

Cheers,
Alana

Hi @michael-day_7391 ,

I can't really comment on what you're seeing in the Artifactory logs (i.e. [1] and [2]), but when an Access Token is specified, that token is sent on requests via a Bearer authorization header (unless Use Legacy API Header is selected). Otherwise, the Username/Password are sent via a Basic header. This happens on each and every request, regardless of whether it's a file download, api call, etc.

Probably just easier to disable authentication during the import if this keeps coming up.

OCI Registries (i.e. what you're using for your Helm charts, as opposed to a regular Helm registry) are not supported, so you'd need to export those files and use disk-based import or something like that.

Cheers,
Alana