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

Hi @mikael ,

We have no plans for this and honestly, I don't think I'd recommend setting up a tool like ProGet in this manner.

Outside of some very specialized use cases (like setting up labs for testing, or nodes in a ProGet Enterprise Edge Computing Edition) I don't really see the benefits. Only headaches.

It might sound fine on paper, but every company that has set it up this way has regretted it. And you will to. The reasons they want "fully reproducible configuration" is usually:

• so we can store configuration in versioned code
• so we can easily replicate it in a testing environment
• so we can easily migrate/move to a new server

Those seem nice, but it totally fails in practice in my experience.

First, you can't "rollback" most configuration. Say you fat-finger a configuration file and delete half your feeds. There go all your packages. And when you realize you've got gigabytes/terabytes of content to deal with, plus all the metadata in storage, this is a huge headache.

The configuration you can make idempotent (say, permissions/users) is so much more a pain to work with than a UI. Again, more error prone you lose all the benefits of visual cues, input verification, etc. You fat-finger the wrong setting, and you get some obscure error instead of a helpful red box next to the text box.

The regret comes in realizing they've created a buggier environment that isn't properly tested, and is somehow less "portable" than an ordinary installation. A year later, when the new team comes in, they usually have to figure out how to "undo" it -- and you can probably guess why we need to get involved to untangle the mess.

Cheers,
Alex

Thanks for the additional feedback @ben_0435

Mostly for my notes, in the five months since @Jonathan-Engstrom shared Microsoft's initial efforts at supporting a WinGet private repository (i,e. winget-cli-restsource), it looks like they've already abandoned their efforts.

• Last code commit June 26, 2025
• Last closed issue July 4, 2025

So at this point, my assessment remans the same: WinGet is basically just the Windows Store, except you it run from the Commandline and has a ton of shady, unvetted packages from internet randos

I feel someone should totally Polymarket whether Microsoft will finish WinGet --or-- just create yet another package manager that's somehow more BingAI friendly.

I'm looking for a solution to titrate that scary giant community repo so it can be managed better... I want upstream.. but only select things. I want to publish apps as necessary for the public/private feed.

I believe that solution is called "Chocolatey"

Hi @fbiryukov_8162,

I did a quick read of the content, and based on this statement ...

"Private Marketplace is available to GitHub Enterprise customers. VS Code users must sign in with a GitHub Enterprise or Copilot Business or Enterprise account to access." sounds to me like a closed ecosystem

And these technical instructions ...

https://github.com/microsoft/vsmarketplace/blob/main/privatemarketplace/latest/README.md#5-connect-vs-code-to-the-private-marketplace

... this is a locked-down / closed ecosystem. There's no published API/specs and no still no support in VSCode for private galleries. They're just "hacking" internal settings to get VSCode to use a different service URL, which they also control.

Obviously this is not something we could/would want to reverse engineer and then support.

If the VSCode team adds support for private repository/galleries (and a public/documented API), and there's some degree of stability to that, we'll consider it. But until then, not much we can do.

Best,
Alex

Hi @dubrsl_1715

I was sure that you must be interested in creating a product that would solve real tasks.

Not really :)

As a products company, we solve problems that a sufficient number of users would be willing to pay for and that aligns with our overall strategic vision.

We also do User-Driven Development, which means we prioritize helping our existing users/customers solve problems instead of adapting the product for nonusers/evaluators like you guys.

We don't consider packagist a competitor nor are we currently marketing users to switich; our solution is similar but not an analog. It requires a change to your workflow.

The PHP/Composer market is already hyper-niche and I'm not convinced there's enough demand to develop a "versionless" package format (i.e. where a version number cannot be discovered in the manifest file or the package file name) format just for this particular use case (i.e. alternate workflow / simpler migration from packagist).

None of the other feed types have this requirement, and it'd be nontrivial to modify our model to support this unique requirement. It would have downstream impacts to features like replication, disk-importing, reindexing, etc.

Thanks,

Alex

Hi @dubrsl_1715 ,

I don't think ProGet is the right solution for you guys. Supply Chain Security and OSS Governance are clearly not concerns, and you're simply not going to get any real value out of a product designed to help organizations solve those problems at the cost of convenience.

I think you will be much better served with the free/OSS repositories for your various repositories; we call that Level 2 in Package Maturity, and I can't imagine any of the "pain points" articulated in that article will resonate.

There's nothing wrong with that. As I've always said, sometimes a Source Control Shingle is the right tool for the job.

Best,
Alex

@felfert I saw the set-up first-hand, though I forgot what files were being edited, a .repo file I think.

But the final setup is something like...

[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/rhel/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey={put the asset download url here, e.g. https://proget/endpoints/...}

... I know basically nothing about rpm so not sure if that helps at all

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

@sebastien-gamby_3349 check with the VSCode team.

They first need to implement support for private repository/galleries, and then we'd need to see some level of stability before considering it.

Hey @splatteredbits ,

We've only had a single request for a private Chef Supermarket over all these years, and I'm almost certain that was from you

My general impression of the market/demand is that Chef has become a "legacy solution" (compared to Docker, K8, etc.), and Progress has no plans to increase its relevance. They appear to be operating in "maintenance mode", and it's kind of like an SVN in a Git world.

There's still some activity on recent packages, but it looks like it's just minor version bumps. I could read this wrong... but I don't think it makes sense for us to invest in a declining platform without a lot of user demand.

Best,
Alex

Hi @splatteredbits ,

I don't think this would be technically possible, at least from my initial review.

Swift has neither "packages" nor "repositories" - the package index is nothing more than a packages.json file that points to other repositories on GitHub.

The client clones those repositories and presumably checks-out a tag to get a specific version. Likewise, to "publish" a package to the Swift Package Index, you submit a GitHub issue.

So I guess, if you wanted a private Swift repository, you'd just need to make a Git repository and follow those conventions?

Cheers,
Alex

@Jonathan-Engstrom they have some hacky something-or-other, but I'd gauge it's at least a decade or two away from being ready for prime time. At least, given their track record on their PowerShellGet/PowerShellGallery v3 launch plans (pushed to 2027.... maybe??)

There's just no appetite for WinGet in the enterprise space, especially since Chocolatey does everything better and has a significantly more reliable / responsive team behind it.

On our end, it doesn't make to try jumping into such an immature ecosystem, especially one run by Microsoft, who's leadership is currently focused on making their BingAI Copilot relevant and selling more Azure web hosting

Windows barely fits into their strategy, let a lone WinGet. But we'll see... maybe the WinGet team can fight against the current enough and increase adoption.

At this point, WinGet It's not a bet I'm willing to take though

@Jonathan-Engstrom suggest asking WinGet team to build support and a use case for private repositories. Currently there is none and thus, it's impossible to use with ProGet.

Until then... WinGet is basically just the Windows Store, except you it run from the Commandline and has a ton of shady, unvetted packages from internet randos

Thanks for the details @mikes_4196

If you're for any kind of control or oversight into your packages (i.e. typical business use case) as opposed to having everyone just rawdog a bunch of shady installers from the internet, I'd definitely recommend looking into Chocolaty again and talk to their support team.

I can't speak to the issues, but that's what everyone is using... and "no one" is using WinGet outside of hobbyists and "shadow IT" devs. There's a good reason for that.

What we would like to have available is download caching.

This just isn't technically feasible due to their terrible design. Keep in mind that the WinGet "repository" is just a giant Git repository with a bunch of .yaml files that point to installer URLs on random urls on the internet.

https://github.com/microsoft/winget-pkgs/tree/master/manifests

From at technical standpoint, WinGet has no real specifications, no ability to script non-MSI installers, no APIs (unless you count git clone as an API), and worst of all no package files.

Open to having my mind changed here, but WinGet remains untenable for any serious organizational usage and has no future until Microsoft decides to build a private repository use case.

Cheers,

Alex

@dimas thanks for that!

We're currently studying/monitoring the performance for public mirroring, and one "concerning" thing I recently saw was a sqllite3 index file explode in file size. We don't know how that happened, but suspect it might have to do with some "aggressive" testing / request cancellation.

Let us know if you spot anything:

https://forums.inedo.com/topic/5410/debian-feed-mirror-performance

Hey @dimas ,

Ah, that makes sense. Looking at the manifest files, they have the same Identity@Id (which is what ProGet uses for the Package Name) but a different Identity@TargetPlatform (which must be new-ish):

<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

We could probably figure something out in ProGet, but it's not trivial when it comes time to changing how we identify Package Names.

Can you try editing the manfiest file inside the vsix archive, and seeing if that works for your use case?

So basically:

<Identity Language="en-US" Id="python-win32-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python-linux-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

Not quite sure if that would work, but figure it's worth a try.

Thanks,
Alex

@michal-roszak_0767 sorry, this is definitely sub-optimal and needs work

Basically, when you have API Key Hashing available, there's no way for the page to filter the incoming requests. So, all of the items are shown. It's not really a trivial to fix and requires us to rethink a bit how we are storing/logging this data. We can explore revisiting as part of ProGet 2026.

@dimas said in Incomplete proget debian connector local index file for ubuntu noble-backports dist:

why does the proget connector omit empty repository components altogether, instead of making them empty like virtually every other Debian repo?

Most other Debian repos use or fork Dpkg to generate the folder structure based on files on disk.

ProGet doesn't. Instead, we parse/index all packages in the repository in a local sqllite3 database. That database has a "Packages" table, and we use that to generate feed indexes (Release, InRelease). It's possible to change, and involves modifying the sqllite3 databases to add a Components table, and then changing the way we generate all the indexes.

It's not too hard but it's not trivial and probably isn't worth it unless we get more feedback on the matter.

Thanks,
Alex

Hi @dimas ,

It looks like VSCode still doesn't support private galleries. I know users have been requesting it for over eight years now.... so maybe it'll come soon! But until then, we can't implement it in ProGet.

I'm not sure what you mean about the python extension... but I do know that a visx file uses some kind of GUID to uniquely identify an extension. If the different "versions" of python visx use that same ID/Version, then I suppose it would get overwritten.

Alex

@steviecoaster the Native API should provide access to all of those procs FYI