administrators

Hi @thomas_3037 ,

The specific issue was already fixed; I'm going to close it because whatever your experiencing is different and the "history" in this long winding thread will only make it harder to understand ,

Please "start from the scratch" as if you never read this.

Thanks,
Alana

Hi @koksime-yap_5909,

They are ordered by the name - so if orderis important to you, I guess you could always do the 10-nuget.org, 20-abc.net or whatever

Thanks,
Alana

Hi @Stholm ,

I assume you saw the Terraform Modules documentation in ProGet?

While updating the Support for Terraform Backends to link to this discussion, I noticed we had some internal notes. So I'll transfer them here:

This would require implementing both the Provider Registry Protocol (for first-party plugins) and the Provider Network Mirror Protocol (for connectors). Both seem relatively simple, though there appear to be some complexities involving signature files.

In either case, we ought to not package these because they are quite large. For example, the hashcorp\aws provider for Windows is just a zip file with a single, 628mb .exe. They also have no metadata whatsoever that's returned from the API.

One option is just to store these as manifest-less packages. For example, hashicorp/aws packages could be pkg:tfprovider/hashicorp@5.75.0?os=windows&arch=amd64. This would be two purls in one feed, which might not work, so it might require a new feed.

Don't ask me what that all means, I'm just the copy/paster

But based on my read of that, it sounds like a big effort (i.e. a new feed type) to try to fit a round peg in a square hole. And honestly your homebuilt solution might work better.

I think we'd need to see how much of a demand there is in the offline/air-gapped Terraform userbase for this. But feel free to add more thoughts as you have them.

Thanks,
Alana

Hi @james-woods_8996 ,

ProGet uses the AWS SDK for .NET, so I can't imagine environment variables would have any impact. I have no idea what those mean or do, but there's probably way to configure those in the SDK.

That said, another user is currently testing a change for Oracle Cloud Infrastructure, which seems to also be giving some kind of hash related error.

Perhaps it'll work for you? AWS v3.1.4-RC.1 is published to our prerelease feed. You can download and manually install, or update to use the prerelease feed:

https://docs.inedo.com/docs/proget/administration/extensions#manual-installation

After installing the extension, the "Disable Payload Signing" will show up on the advanced tab - and that property will be forwarded to the Put Request. In theory that will work, at least according to the one post from above.

One other thing to test would be uploading Assets (i.e. creating an Asset Directory) via the Web UI. That is the easiest way to do multi-part upload testing.

If it doesn't work, then we can try to research how else to change the extension to get it working.

Thanks,
Alana

Hi @philippe-camelio_3885,

Can you clarify what you've tried to date, and the issues you've faced?

You can silently install the Inedo Agent, or even use a Manual Installation process if you'd prefer.

Ultimately it's a standard Windows service, and you can change the account from LOCAL SYSTEM (which we recommend, by the way) to another account using sc.exe or other tools.

Thanks,
Alana

Hi @jw ,

Technically it's double, though it's not trivial due to the number of places the change would need to be made and tested... ProGet API, pgutil, docs.

The code/title change itself looks trivial (i.e. just pass in External_Id and Title_Text to the call to Licenses_UpdateLicenseData), though I'm not totally clear what to do about the other one. What does pgutil send in? Null? []? Etc.

As a free/community user this isn't all that easy to prioritize... but if you could do the heavy-lifting on the Docs and pgutil (i.e. submit a PR), and give us a script or set of pgutil commands that we can just run against a local instance... I'm like 95% I can make the API change in 5 minutes.

Thanks,
Alana

Hi @jlarionov_2030 , easy change! We will not require a valid license for Settings API Endpoint going forward; PG-3133 will ship in next maintenance release, scheduled for Friday.

Thanks for pointing this out! We missed this detail of the APKINDEX specification and will get this fixed as PG-3132, likely in this week's release of v2025.12 on Friday, but potentially in a later maintenance release if it is more complex than expected.

Hi @tobe-burce_3659 ,

We do not support deleting or modifying any of the contents under the program directory; they will simply return when you upgrade and it may cause other problems.

Instead, please create an exception; we are aware of the vulnerabilities in libraries that Postgresql uses and can assure you that they are false positives and will have no impact on ProGet... even if you were to be using PostgreSQL.

Using virus/malware tools to scan/monitor ProGet's operation causes lots of problems, as these tools interfere with file operations and cause big headaches.

Thanks,
Alana

Hi @fhusson_1634 ,

From a quick read of the documentation, it looks like an "MCP Registry" is basically a list of "MCP Servers", which is basically a JSON document that describes.... an API or something?

What I'm not seeing are "Packages" (i.e. an archive file with a manifest file) nor a "Central Repository" (i.e. a canonical location where OSS Models are stored). If that's the case, I'll do a "hard pass" on this for the forseeable future -- there's not much value ProGet could add here and we'd have to add a completely separate, non-package subsystem like Assets or Docker.

Let me know if I misread the specs

Thanks,
Alex