@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

Hi @jonathan-simmonds_0798, Thanks for the suggestion! This has been a long-standing wish-list item, but it's deceptively complicated. The "current idea" is a feature called "raft analysis" that will create a list of all raft items that depend on other raft items. For example, a pipeline that references a script. Or, a script that calls a module, and so on. It could also detect warnings/errors and report them. Creating this list often involves opening thousands of files and "parsing" them, which is not a trivial operation... but we're only talking "a few minutes" in most cases. However, the main challenges arise with invalidating this list (many edits will cause that to happen), and then communicating the status of the rebuild to users. I'll add a note to our BuildMaster 2026 roadmap though and see if we can explore it again; the current focus is boring..... modernization (PostgreSQL). That said, you probably noticed it but.... you should be able to see if a particular pipeline has an error (like a missing script) on the piepline overview page. Not as nice. Thanks, Alana

Hi @parthu-reddy , At this time, we don't have a disk cleanup procedure for local storage like this; we may add it in the future, but for the time being you can just delete them. The LocalStorage folder is ephemeral -- not quite "temp" storage, but the contents can be deleted. They will just be recreated next time it's needed. Thanks, Alana

Thanks, that worked! We've had problems with this repo before as directory browsing isn't allowed due to the fact it's hosted on S3, so it breaks some software if you just put in the folder path. I guess ProGet is properly just appending the usual location of the repodata file instead of requiring the ability to browse the root folder.

Hi @koe , This is definitely a problem that you can solve with BuildMaster, but before giving any kind of technical guidance, I'd like to understand the business processes. On first glance, this sounds like one of two scenarios: Quasi-custom Software, where you create a customized build of a software application (perhaps bundled with their plugins, etc) User-driven Deployments, where you maintain a single application but deploy a new version of that application based on user requirements (new feature they requested, bug fix, etc) Are either of those close? Whatever the case, can you describe the decision-making process or rationale that goes into "deploy a software release to either all production systems, all test systems or just a single one out of all these systems?" Are there different types of releases (e.g. a "patch" release of an old version)? Or is everyone "forward only, latest version"? BuildMaster is, of course, an automation platform - but more importantly, it's about modeling process and visualization. And when it comes to process, consistency is key - even when there are variations. We don't believe a decision like above is "arbitrary, and based on the whims of an application director", but there's probably some rationale that goes into it. So, with BuildMaster, our goal is to help get everyone on the same page about which process to follow for different releases. Anyway, how you model this will have a big impact down the line. Cheers, Alana

Hi @Nils-Nilsson , Good news - this is actually on our ProGet 2026 roadmap. The general idea is to "reuse" Feed Groups -- I guess we'd call them "Feed & Project Groups" or something? Anyway, the projects would be grouped in the UI similarly, and you could scope project-based permissions to a group. We will try to get it as a preview feature in the coming weeks, assuming it can be done in low risk. It seems like this would be the case. Cheers, Alana

I have downloaded ProGet 2025.0.19 and was able to successfully change the location for that last setting. Thanks.

Hi @geraldizo_0690 , Thanks for the report! Sometimes bug fixes are a single character like this ... [image: 1769504251057-1c7d2a43-f6ca-41b0-9853-65cdea7cb5b7-image.png] It'll be be in the next maintenance release via PG-3205 :) Cheers, Alana

Hi, our Proget instance was updated to 2025.19 (Build 14) and the above described issue disappered. Excellent! Thanks!

Hi @davidroberts63 and @mikael , Thanks for the insight and ideas! I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run? Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me. Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;) I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on. Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file. Cheers, Alex

Thank you. Does it mean that I must stay with the SQL server version and do not migrate to the one with PostGres.