Hi @nachtmahr,

Yes, that's what I would reommend doing -- using the internal storage path. Just make sure to NOT select the option to delete the files and make sure to select "search subdirectories" so everything will be imported.

Cheers,
Steve

Hi @nachtmahr ,

There is no "clone" method per se, but you can accomplish this by bulk-importing packages into a new feed: https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import

Cheers,
Steve

Hi @tim-vanryzin_8423 ,

Great question on developer experience! We're very curious to learn that ourselves, so please let us know as you implement it.

First and foremost, if you haven't already, check out the Recently Published & Aged Packages rules blog article to see how this works and our current advice. FYI - we are likely going to change the best practices guidance in 2026 to discourage download blocking.

From an API/technical standpoint, it's simply not possible to "hide" the fact that 1.12.15 is the latest version. So, if you have a connector, ProGet will report the latest version as reported by the connector.

But even it were technically possible, there's no simply great developer experience here. Keep in mind that most never look at the ProGet ui -- they configure things once, and forgeet about it.

So really, it's just a question of when you want the developer to find out they can't use Xyz-1.12.15. Here are the general options:

• Manual Curation (no connectors) - it's always going to be on nuget.org / npmjs.org, so even if you manually curate every page in ProGet, they'll know it exists and will be confused why it's not on ProGet; they may not even know who to ask
• Download blocking - you could simply block downloads of newest packages, but that's just going to look like random "400 errors" to developers and they will become frustrated
• Build Auditing - run pgutil builds audit on your build server, and you can see if the packages are noncompliant; this is where we are shifting our advice, as a failed build at that stage will be so much more obvious than a 400 buried in a package restore step

Ultimately this requires training developers to use lock files and not always get latest. That's why we are shifting to pgutil builds audit -- it's almost self-training. When their builds fail, they will see the reason clearly and should be able to adjust their code/configuration to not use a non-compliant version.

-- Dean

Hi @jonathan-werder_8656 ,

Thanks for clarifying! I'll be honest, I had no idea where you were getting configuration files in the first place... and I forgot that was ever a thing. Sorry about that.

Anyway, I don't think that this has worked in years, and it's most definitely not something we'd recommend today. We'll try to track it down and remove it in the docs / help text.

For your use case (automated installation) just use pgutil settings to set that value.

Thanks,
Steve

Hi @henderkes,

I'm not familiar with module streams, but if you tried it in ProGet and it didn't work then likely not? It sounds like a different API/endpoint, but I haven't researched it at all.

However, based on how you described it ("removed from Fedora 39"), it sounds like one of those "good but old" technologies that don't make sense for us to implement.

Thanks,
Alana

Hi @jonathan-werder_8656 ,

You can set this value under Admin > Advanced Settings.

Thanks,
Steve

Hi @pmsensi ,

You'd need to run through a proxy like Fiddler or ProxyMan, which can capture the outbound / inbound traffic. Or if you provide us with a URL/API key we might be able to play around and attach a debugger. You could always create a free trial or something and set it up that way.

First thing that comes to mind is that your endpoint is incorrect and you may need to "play around" with the URL. Typically it's like this:

• endpoint is https://server.corp/path/my-pypi
• index file is https://server.corp/path/my-pypi/simple
• ProGet automatically appends /simple unless you specify otherwise on Advanced

The "Simple " endpoint is just a list of HTML like <a href="...">. That's what ProGet/connectors/pypi follow.

Thanks,

Steve

Hi @ayatsenko_3635, @dubrsl_1715,

Thanks for the feedback and continued discussion.

So, our Composer feed is relatively new, so we are open to exploring new ideas. One option might be to do an "import" of packages into ProGet, similar to how we handle connectors in Terraform feeds. But that's something that could also be done with a script, so we'd want to see what that looks like as a prototype.

That said, we definitely can't implement "content pointers" to Git repositories. The Git-based "package" model is not only outdated but it has several "fatal" Software Supply Chain problems.

The biggest problem, by far, is that package content is hosted by a third party (i.e. GitHub) and managed by another third party (i.e. the repository owner). At any time, a package author or the host can simply delete the repository and cause a major downstream impact - like the infamous left-pad incident in npm.

This is why other package ecosystems have adopted a "read only" package repositories and disallow deletes (except for rare cases like abuse). Once you upload a package to npmjs, nuget, rubygems, etc. -- it's permanently there, and users can always rely on that being the case.

That's simply not possible with Git-based "packages". The "content pointer" must be updated periodically updated, such as if the author decides to move the Git repo to GitLab, Gitea, etc. Now you no longer have a read-only package repository, but one that must be editable. Who edits? Are they tracked? What edits are allowed? Etc.

There are several of other issues, especially with private/organizational usage, like the fact that there's no reasonable way to QA/test packages (i.e. compared to using a pre-release/repackaging workflow) and that committing/publishing are coupled (i.e. you tag a commit to publish it). This makes governance impractical.

And that's not to mention the fact that there's no real way to "cache" or "privatize" third-party remote Git repositories. Unless, of course, you mirror them into your own Git server... which is technically challenging, especially if the author changes hosts.

We first investigated feeds years ago, but they didn't have package files at the time -- only Git repository pointers. Like Rust/Cargo (which used to be Git-based, and still technically supports Git-based packages), we anticipate this same maturity coming to Packagist/Composer as well.

So while we certainly understand that this is a workflow shift, it's a natural evolution/maturation of package management. Likewise, it took decades for the development world to shift from "file shares" and legacy source control to "Git", but that's what everyone has standardized on.

That's the world ProGet operates in, so it might be a bit "too far ahead", or we might be misreading the tea leaves - but a "package mindset" is a requirement in using ProGet. But hoepfully we can make that easier, possibly with exploring "package imports" or something like that.

Cheers,
Steve

Hi @frank-benson_4606 ,

Thanks for clarifying, that makes sense.

I'm afraid that ProGet does not "crawl" the parent artifacts for metadata; we had considered it, but it's rather challenging to do from an engineering standpoint, difficult to present crawler errors, and fairly uncommon.

Thanks,
Steve

Hi @dubrsl_1715 ,

Thanks for the clear explanation; I'm afraid your best bet here is to "take the plunge" and adopt package management best practices. A key tenet being a "self-contained archive file with a manifest" that is read-only and "cryptographically sealed" (i.e. hashed).

A "pointer to a Git commit" seems convenient at first, but there's a good reason that many ecosystems (including Composer) have moved away from it -- ultimately it's just not scalable and doesn't handle team workflows very effectively.

This will likely involve updating your composer.lock files and also the way you publish packages. In general, your process for creating a new version of a PHP packages should look something like:

1. Checkout code
2. Modify composer.json file with a version number
3. Package the file
4. Publish to ProGet

As you get more mature, you can get into pre-release versioning and repackaging.

Hope that helps,

Steve

Hi @frank-benson_4606,

I looked into this a bit closer now.

Looking at the commons-io-2.14.0.pom, there is no Licenses element specified. The pom should have that, and it'd be nice if the package authors added it; if you requested that via a pull request or issue in their github, I'm sure they would. That said, that's why it's not showing in ProGet.

This is why you see the unknown license detected, and that means you have to click "Assign License Type to Package" for ProGet to associate the package/license. I assume that you did that on 2.14.0, and selected Apache-2.0.

By default, that selection only applies to the specific version, and if you wanted it to apply to all versions of commons-io (including future ones not yet published) you'd need to click on the "Apply to all versions".

If you navigate to SCA > Licenses, and click on Apache-2.0, you can see the assignment to the package under the "Purls" tab. It would show: pkg:maven/commons-io/commons-io@2.14.0 for the version you selected.

You will need to either do this for all versions or decide if you want to add an entry to the Package Name tab (i.e. pkg:maven/commons-io/commons-io) under the Apache-2.0 license definition.

Thanks,
Steve

Hi @sneh-patel_0294 ,

What I mean is, in your browser, open multiple tabs -- one for /administration/cluster on each node in the cluster, bypassing the load balancer. All nodes should show "green" for that.

The one that shows "red" still has the wrong encryption key. Modify the encryption key, and restart the servicies, and reload the tab, and it should work fine.

Thanks,
Steve

@sneh-patel_0294 to restart the services, you can do so from the Inedo Hub or the Windows Services (look for INEDOPROGETSVC and INEDOPROGETWEBSVC). If you're still using IIS, make sure to restart the app pool as well

Hi @sneh-patel_0294 ,

This message means that the decryption keys across machines are different, which result in exactly the behavior you describe (403s, logouts):
https://docs.inedo.com/docs/installation/configuration-files

I know you mentioned you already checked, so there's likely a typo, miscopy, looking at the wrong folder, etc. Note that the folder is %PROGRAMDATA%\Inedo\SharedConfig\ProGet.config, as opposed to C:\ProgramData\Inedo\... - on some machines, the program data folder is stored in a different location.

I would also make sure to restart the service/web as well. To test, you can try loading that tpage on all nodes and you should not see "Encryption key decryption failure" when refreshing the nodes.

Hope that helps,
Steve

Hi @frank-benson_4606 ,

This appears to be a known issue that will be fixed in 2025.15, releasing this Friday, that causes certain URL-based licenses to not be detected (PG-3153).

If you're using Docker, you can try upgrading to inedo/proget:25.0.15-ci.4, which should have that fix in it.

Thanks,
Steve

@jw good call, we'll get this fixed via in this week's release via PG-3161

Hi @k-lis_1147,

Sorry on the slow reply; we did not get a chance to investigate in last release, but it was on the list this week. That being said, it was also an easy fix (didn't anticipate it to be a copy/paste fix)-- and we'll get it via PG-3160 in this week's mainteancne release.

Thanks,
Steve

Hi @frank-benson_4606,

Whoops, it looks like that was kept in the documentation by mistake; I just removed it now.

We had planned that feature way back in ProGet 2023, but it never was implemented. That feature -- as well as some of the more advanced license compliance ideas we had -- have since left our roadmap due to a total lack of interest from end-users.

The main reason for lack of interest is that the pgutil builds audit lists all packages and licenses. So, most users found that to be sufficient. They just hand that list to the legal team, who creates that amendment. So perhaps that will suffice in your use-case as well.

Let us know if not, always open to hearing more.

Thanks,
Steve

Hi @frank-benson_4606,

ProGet's license detection requires generally that a package is cached or local to ProGet in order to detect the license. When you visit the package page, a request is being made to download the metadata from the remote connector, which is how you can see the license in that case.

That being said:

• you can enable OSS Metadata Caching, which will perform these requests on remote packages -- but it's obviously a performance hit
• there is a known bug (fixed in 2025.15, releasing Friday) that causes certain URL-based licenses to not be detected (PG-3153)

Hope that helps to troubleshoot. A prerelease version of 2025.15 is vailable should be interested

Thanks,
Steve

Hi @rick-kramer_9238,

That vulnerability is in our database as PGV-2228003, and it shows up when I view that package:

If you can provide more details about what you mean by " the report is telling us no vulnerabilities are detected" I can investigate further.

Thanks,
Steve