Hi @certificatemanager_4002 , Check out our Licenses for Non-production / Testing Environments for the full details. But if its a short-term migration testing scenario, then using an existing or trial key is fine. For a long-term environment, a separate license is required. -- Dean

Hi, Fashionably late here, but what @atripp said is accurate. Chocolatey's moderation process on the Chocolatey Community Repository is a completely separate process to the vulnerability management features available in ProGet. Our moderation process was put in place shortly after the Chocolatey Community Repository went live 15 years ago, and some packages were added to the feed and haven't received updates since then. While our moderation process is really good, and we've never seen malicious content make it to approved status, you should always detonate-test a package in your own environment before promoting it to a production repository.

Hi @Valentijn, We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available. Thanks, Rich

@dean-houston By way of follow up, unfortunately the verbose output of an apt update against the jenkins repo provided exactly 0 clarity. apt update -o Debug::Acquire::http=true Ign:1 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:2 https://pkg.jenkins.io/debian-stable binary/ Release Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. I appreciate the help in trying to make this work, but I am going to punt on this and just grant the specific server access directly to pkg.jenkins.io.

Hello, Great news! Thanks, Scott

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