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

Hi @yaakov-smith_7984 ,

This behavior is expected and by design. "Deprecation" and "Unlisted" are server-side metadata (i.e. stored in the remote repository, not the package itself), and once a package is brought into to a different server (i.e. ProGet), it's "disconnected" from the other server.

That being said, there is a feature in ProGet that can routinely "sync" this server-side metadata:

• https://docs.inedo.com/docs/proget/sca/howto-deprecated-package-alerts
• https://docs.inedo.com/docs/proget/sca/policies#oss-metadata-updating-caching

This feature obviously comes with some performance costs, though you'd really have to enable it to see if that has any impact on operation.

Another approach is to use a retention policy that deletes cached packages older than 90 days.

Thanks,
Steve

Hi @frei_zs,

Based on the fact that unpackaging/repackaging it works, there's definitely something "wrong" with the original package file.

Debian uses a tarfile format, and there are several "buggy" tarfile writers that don't get the format quite write. If I remember correctly, some ancient versions of dpkg wrote these files incorrectly. Some tarfile readers account for these errors while others (perhaps including ours) do not.

We may be able to attach the file to a debugger and give more details, but if this is a one-off or rare circumstance, than I would just repackage it and not worry about it.

Thanks,
Steve

Hi @jw ,

Did you try this on a new instance, or did you discover this on your (older) instance?

This was a known issue through several versions of ProGet 2025, and it impacts mostly SCA as you noticed. However, the vuln updater has since been fixed, so it shouldn't be continuing.

The "feed reindex" function can also merge/fix these duplicate names. They should be detected during a "feed integrity" check, and show as a "warning".

Thanks,

Hi @koksime-yap_5909 ,

I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc.

The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help.

This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first.

Hope that helps, let us know if you have any other questions!

Thanks,

Steve

Hi @koksime-yap_5909 ,

Good catch; that is most definitely a bug. I just checked, and it's isolated to assets - packages and Docker images work as expected.

This will be fixed in the upcoming maintenance release via PG-3150; it's shiping Friday, but we can provide a pre-release if you're interested in testing earlier.

Thanks,
Steve

Hi @koksime-yap_5909,

In the event that the artifact has not been downloaded (i.e. the last download date is "null"), then the publish date will be considered. So if you set "90 days", then an artifact will be deleted at earliest, 90 days from publication if it hasn't been downloaded.

Thanks,
Steve

Hi @koksime-yap_5909,

The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as.

On ProGet 2025, the command is proget or proget.exe We should update the docs for sure

Thanks,
Steve

Hi @Sigve-opedal_6476 ,

There are some known issues that we intend to fix with PG-3144 in the next maintenance release (scheduled for Friday). This will likely be resolved then.

The inedo/proget:25.0.14-ci.10 container should have these changes inthem, if you'd like to try it out sooner.

Thanks,
Steve

@yakobseval_2238 thanks for letting us know, I just updated it!

Hi @k-lis_1147,

Based on what you described, it should show up.

Can you confirm what feed type you're using, and whether or not you're using PostgreSQL (this is the default for ProGet 2025).

I just discovered a bug (PG-3145) that would impact PostgreSQL (all feeds probably) and certain feed types on SQL Server (Maven) that would cause that information not to display on that page.

Easy fix, but just want to double-check

Thanks,
Steve