Hi @frei_zs,

ProGet 2025.12 does not support the PGP v3 format, and there's no way you can get it working. So, you'll need to upgrade to the latest version, which does support the format.

Here's some more information on the changes:
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds

Cheers,
Alana

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

Hi @michael-day_7391,

ProGet is not designed to provide many details on network- or OS-level errors; that's where tools like Invoke-WebRequest come in. And it sounds like you've already discovered the root cause (failed certificate revocation check) that way.

Anyway... when hosting ProGet on Windows, the Windows network stack will be used. So, if Windows is refusing to connect for whatever reason, then ProGet will also not connect. There's unfortunately no way around this, and we do not allow bypassing of SSL in ProGet.

The good news is, once you get Invoke-WebReuqest working, then you'll be able to connect. There's probably some magical registry setting out there that will help :)

Cheers,
Alana

Hi @mayorovp_3701

Actually zero byte in position 1 looks like attempt to read UTF16-LE-encoded json as UTF8

Oh that's a great observation! Yeah that sounds like a reasonable explanation. But still... how could that even be possible?

It's not like ProGet is going to randomly swap an encoding like that, and it's not like NuGet is going to store .json files incorrectly.

As for experimentation, next time it happens:

• remove one of the connectors from the feed to which one
• navigate to the JSON endpoints of the connector in question, to see if you see the bad JSON
• try to identify a pattern of behavior that causes this
• watch for HTTP access logs to see if you can find the exact URL that's being accessed at the time of the connector failure (assuming it's a self-connector)
• be prepared to attach a MITM proxy to ProGet (Admin > Proxy)

Thanks,
Alana

Hi @mayorovp_3701,

That's a really strange error; it's basically saying that, somehow, a 0x0 character found its way into some JSON returned by the API. This character is invisible, and you'd need to use a kind of hex editor or developer tool to even see it.

I guess, in theory it could be inserted by some intermediate device (firewall, gateway, etc), but who knows at this point. I can't imagine how that could happen on either NuGet or ProGet, but that's the first place to start looking.

I suspect the server restart is unrelated; that certainly wouldn't cause a random 0x0 unless there's something really broken with the computer.

From here, you'll want to keep isolating the issue, and try to figure out which connector is "bad"

• If it's NuGet.org -- the issue is most certainly a network/gateway that's doing that.
• If it's ProGet -- it's likely some strange bug, where 0x0 got inserted to the Database for a connector or feed or something. We saw that during some migrations, but it's realy hard to track down.

I would just keep experimenting. If it's related to a reboot, just stop/start the service. That should be the same.

Thanks,
Alana

Hi @michael-day_7391,

That's just a generic SSL error, which as you may know, is happening at the operating-system level. That quick-connect screen won't provide details. There may be a redirect happening, but it's hard to say.

It's unusual that it would work from the web browser, but also not uncommon. If you use Invoke-WebRequest that would reproduce the error. If not, then stop the service and run ProGet manually (proget.exe run) so it's the same user/account.

You should also be able to get a stack trace by adding a connector; that would be logged as a connector error.

Thanks,
Alana

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

Hi @mikael ,

Oh sorry, we decided not to refactor/rewrite the API after all -- and I guess we threw out all the "ideas" attached to that initiative as well. This was on our roadmap for several years, so we didn't realize there was a customer-facing request attached, hence how so we forgot.

Anyway, I've moved this back as feature request, and we'll look to add this to the existing API. It probably won't be that bad! Please stay tuned, hopefully we'll evaluate within the next couple weeks.

Cheers,
Alana

hi @michael-day_7391 ,

The correct connector URL would be:

https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.31/rpm/

I added that connector and coould see/browse/download packages in the repository.

Thanks,
Alana

Hi @michael-day_7391 ,

I guess not? I've ever heard of StarTLS, and no one else seems to ask -- so it's probably not worth investigating. I guess LDAPs is what's popular, so probably easier to just go that route.

Thanks,
Alana

Hi @caspacokku_2900 ,

Yeah it's pretty weird. The errors are all over the place - not like in a specific database query or anything like that. This also isn't a sign of server-overload that we've seen.

It's as if internal network connectivity is somehow breaking within a container? Or there's "something else" wrong with the internal PostgreSQL server? These are all "deep system" level errors in basically operating-system level code (drivers, etc).

We've seen this with another user with really weird errors, but no idea on how to reproduce it. Maybe it's an "error reporting an error".

As for the feed... there's nothing special about cargo vs other feeds from an API/usage standpoint. If anything, npm hammers the server a lot harder with its 1000+ package restores. And this has nothing to do with connectors.

Unfortunately we don't have a lot to go on:

• how about increasing hardware
• can you try a different physical server
• could it somehow be the underlying operating system?
• any patterns as to when this is happening (lots of traffic etc)

Any clues or consistency would help.

Thanks,
Alana

Hi @geraldizo_0690 ,

Thanks for the report! Sometimes bug fixes are a single character like this ...

It'll be be in the next maintenance release via PG-3205 :)

Cheers,
Alana

Hi @caspacokku_2900 ,

I'm afraid these errors aren't related to Cargo, but are indicating some kind of system/network error. In some cases, there's a unexpected/broken network configuration between the ProGet application and the underlying database (PostgreSQL).

In other cases, it appears to be related to connections to cargo's public repository.

So bottom line, this is an environment-specific issue. Can you tell us a bit about your configuration? How about a Paste of Admin > System Information?

Thanks,
Alana

Hi @michael-day_7391 ,

These days, it's it's considered a "UX best practice" to provide minimal options in the installer because it's fewer choices to make when you're unfamiliar with the tool. Instead, programs should allow these to be configured post-installation. Most modern tools have shifted to this practice, including our products.

As for the folder, the ProgramData folder is indeed the standard/recommended practice on Windows. If you're still configuring Windows using multiple drives/partitions (less common these days w/SSD), you should definitely change the User/ProgramData directories during provisioning:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/relocation-of-users-and-programdata-directories

Many Windows programs (including ProGet) will use these to store application data, and it can balloon to gigabytes if you're not careful.

Thanks,
Alana

Hi @michael-day_7391 ,

There is an option to "Use LDAPS", so I would makes sure to select that.

Thanks,
Alana

Hi @michael-day_7391 ,

This folder is for ephemeral, temporary storage. The only time it will require a lot of space (hundreds of MB) is you're doing things like proxying public debian repositories.

So maybe you want to change the wrong folder?

Perhaps you are looking for the PackageRoot instead?

Thanks,
Alana

Thanks @certificatemanager_4002 -- that will definitely work if you're using inedodb (i.e. settting up a cluster), though for using a single-server instance, inedodb isn't recommended.

@Sigve-opedal_6476 I'm not super-experienced at Linux myself.... but if the container is stopped, then you should be able to just move/copy the files. The container must be able to read the files -- I do know there's some kind of permissions/user error when things aren't set right.

I'd share the database error when you restart.