Hi @jolaka9284_9458,

Thanks for providing all these details. I was able to pinpoint the reason for the slow down and why it specifically happens on some crates and not others. This is related to some code that we have to determine when to point cargo to pull dependencies from ProGet vs crates.io. Specifically this comes from cargo's API specs for dependencies:

registry — cargo metadata uses a value of null to indicate that the dependency comes from crates.io. The index uses a value of null to indicate that the dependency comes from the same registry as the index. When creating an index entry, a registry other than crates.io should translate a value of null to be https://github.com/rust-lang/crates.io-index and translate a URL that matches the current index to be null.

As you can see, the value specified in the metadata is different than the value the index needs to return. In ProGet, we will return null if the package exists in the feed (including connectors) and https://github.com/rust-lang/crates.io-index if it does not. This is to support the case when ProGet is not used as a mirror and instead for only local crates. Unfortunately the use ProGet as a mirror option is stored only in the client config and is not sent to ProGet.

This is the reason why crates with a lot of dependencies take longer to generate the index than ones that don't and why you'll occasionally get timeouts, but after the retry it works. We have some caching on this to help with performance, but it's not a forever cache.

I'm going to work on some potential improvements for this and will let you know when I have a solution ready. Unfortunately, the only workaround we have for this currently is to use a package approval workflow (like our npm Package Approval blog article).

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @barnaby-williams_8489,

Please see our documentation for cloud storage. There is a subsection for migrating a feed to cloud storage.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @toni-wenzel_6045,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making a GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @philipp-grathwohl_1687,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making an HTTP GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to HTTP POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @Nils-Nilsson,

We identified the issue with the UI and have fixed it in PG-3277. This will be released next week in ProGet 2026.1.

As for the UserNotFoundException after the rollback, that is most likely related to your cookies. Once the cookie expired, it then let you login again. You can verify that by using an private/incognito window and logging in or clearing your cookies and logging in again.

Thanks,
Rich

Hi @cole-brand_2889,

I have identified the issue, PG-3268, and this should now be fixed in ProGet 2025.27. Please upgrade to 2025.27 and see if that resolves your issue.

Thanks,
Rich

Hi @geraldizo_0690,

Thanks for providing all of this information. I was finally able to recreate the issue. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27. Just to make sure I cover all my bases, can you tell me which database backend you are using?

Thanks,
Rich

Hi @kien-buit_2449,

This is partially fixed in our vulnerability aggregator. You should see alpine vulnerabilities showing up next time your vulnerability updated runs. I also recreated a situation where certain packages may not be removed upon update of the vulnerability. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27.

Thanks,
Rich

Hi @sigurd-hansen_7559,

This is a known issue, PG-3246, and will be fixed on Friday in ProGet 2025.25.

Thanks,
Rich

Hi @sigurd-hansen_7559,

We can add back support to not do the recursive search. If you would like to use a search scope, we would recommend using the OpenLDAP/Generic LDAP user directory and specifying your own LDAP queries. With that said, I think that is overkill for this situation and adding a way to disable recursive groups will be the easiest. I will get that added on the April 3rd release of ProGet 2025.25.

Thanks,
Rich

Hi @sigurd-hansen_7559,

Let me start with a little background in V5 vs V4. With V5, our goal was to only support Active Directory because we have since created an OpenLDAP/Generic LDAP specific user directory. This allowed us to strip out the extra LDAP querying we had to do in V4 to support both. This significantly reduces the amount of LDAP queries to look up a user. It also allowed us to lean into specific Active Directory LDAP features that we could not do when supporting both.

One of those features we can now use is the built in LDAP query for a user's groups and a group's members. When we look up groups we use the following LDAP query:

(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=«USER_DISTINGUISHED_NAME»))

This means that we will return all groups (including nested groups) just like how Active Directory would on Windows without having to make a circular walk of the groups tree in a single LDAP request.

Could you answer a few questions for me?

1. Is your ProGet instance running on Windows or Docker?
2. When you say significant group memberships, approximately how many are there? (~10, ~20, ~50, etc...)
3. Is your domain part of a multi-directory forest?
4. In your V4 user directory, can you change the recursive group search to "Recursive Search (Active Directory Only)" and see if you see the same slow downs?

Thanks,
Rich

Hi @gbeckett,

Glad to hear it is working for you! Please let us know if you run into any other issues.

Thanks,
Rich

Hi @gbeckett,

I just pushed out a pre-release version of ProGet 2025.24-rc.3 and can be installed via InedoHub. Please see our our guide on installing pre-release verions for more information. Please let us know if you have nay problems.

Thanks,
Rich

Hi @phil-sutherland,

Thanks for sending this over to us. This looks to be a regression in the PostgreSQL migration. I have created a ticket, PG-3241, to fix the issue. This will be fixed in the next maintenance release of ProGet 2025.24, due out on March 20, 2026.

Thanks,
Rich