proget:25.0.22-ci.4 seems to work. The CPU consumption stays steady while ProGet is not under heavy load. The Debian connectors does not grow infitely. So for the third day this is the output: root@xxxxxxxxxxxxxx:/usr/share/ProGet/LocalStorage/Connectors# du -chs * | grep G 2.6G total I'll get back to you on this in a week. Thank you for the support.

Hi @parthu-reddy , Sorry on the slow reply, check out the link I sent you via t icket! Just let us know when you upload the files and we'll talke a look then! Thanks. -- Dean

Hi @tyler_5201, The UI package search is pretty basic, so it's not going to look through those metadata properties. They are something you could obviously search/find through the API. Depending on what you're trying to do, we do have a Whitelabel feature that makes the UI a lot easier to consume for end-users: https://docs.inedo.com/docs/proget/administration/whitelabel https://inedo.com/proget/case-studies/salient In particular, the "Tile View" on Universal Packages may help. But it's not very popular and is something we work closely with our users on, so let us know if that's of interest. -- Dean

Hi Rich, thanks for the additional pointers. We will look into it some more and report back next week earliest due to some other priorities this week. Best regards, Sirko

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 @Sigve-opedal_6476, I haven't been able to reproduce this in a Rocky 9 test environment. After setting up the feed and connector in ProGet I ran dnf install zabbix-sql-scripts, and then repeated the test a few times with different versions and variations on formatting the versions. I also tried with cached and uncached packages. I was able to get a 404 to happen one time, but it was due to the upstream repo returning a 404 at the correct URL - which then worked the next time it was tried. Is this happening consistently for you?

Thanks for the comprehensive response - which was very helpful. Closing the loop, we've elected for the short term to run up a parallel aptly server to manage our existing apt snapshots, but in the longer term we'll revisit how we use snapshots at all and very likely will switch our process to use upstream provided snapshots.

Hi @caspacokku_2900, Thanks for posting this! We are happy to hear you up and running! We are currently reviewing a default value for the concurrent request limit in ProGet. As more and more package managers push towards a larger dependency tree, this limit is becoming a requirement for some feeds (cargo, npm, and NuGet being among the highest). Thanks, Rich

Hi @michael-day_7391, Thanks for sending this over! We'll get this resolved within the next couple of maintenance releases of ProGet. Thanks, Rich

@stevedennis I understand. Thank you for your fast Reply and explanation. I see why it can be troublesome and actually go against Proget's core functionality to allow what I was talking about. Thanks! Regards.

@stevedennis I see, Thank you for your fast reply. Regards.

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

Thanks. I've installed certificates on our domain controllers, and now I can connect properly with LDAPS and login via my domain account.

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

@atripp Ah, thanks, I did not read https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds well enough, my bad, sorry. I'll talk to DevOps about the update then. Thanks for the fast reply! Best, Frank

Hi @mikael , We plan to add this support via PG-3213 in an upcoming maintenance release -- perhaps Feb 20 if all goes well! Cheers, Alana