Hi @tcochran_0018,

This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.

Thanks,
Dan

Hi @kichikawa_2913,

Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week!

Thanks,
Dan

Hi @kichikawa_2913,

Thank you for following up with us and letting us know it is working now. Also, thanks for clarifying the Docker network setup for me. This is related to how we changed the service messenger in ProGet v6.

I took a deeper look into the code and when setting the endpoint via the "change" link, it will override the configuration's shared value. Once that has been set, it will use the configuration associated with that node instead.

Based on your screenshot, it looks like it was using tcp://*:6001 as the shared configuration (even though you said not to), but failed to connect because it was trying to balance amongst the other nodes. If you were using a Docker network, this most likely would have worked because the individual nodes could have listened on 6001 as well.

After reviewing these changes, you would have to change the service messenger address on each service node in order to apply the configuration you are looking to use (which is what you did above).

Hopefully this gave a bit more context to this change.

Thanks,
Dan

Hi @kichikawa_2913,

Thanks for following up and letting us know that you found the solution!

Thanks,
Dan

Hi @claudio_9251,

I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that.

Thanks,
Dan

Hi @dm-sidelnikov_5266,

I see the email, thanks for sending this over! Please give me some time to review and I'll let you know what I find.

@pieter-mertens_0372, your issue may be related. Although both products are owned by Microsoft, they still differ in their implementation. Does this happen for all packages or just a specific subset?

Thanks,
Dan

Hi @arozanski_1087,

We talked it over in our team meeting yesterday and decided to change ProGet to always create a new release when one doesn't exist and add new dependencies when the release does exist. This way that parameter will not be needed. So you will just need to upgrade ProGet to v2022.23 when it is released later today.

As for the Yarn support and scanning multiple package types in the initial scan, we plan to work on that early next week, so we should have something for you soon.

Thanks,
Dan

Hi @itops_6398,

I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look.

With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later.

Thanks,
Dan

Hi @forbzie22_0253,

You can do this using our Bulk Import via a drop path feature. We have a helpful How To Bulk Import Packages Into A Feed From Disk article in our documentation.

Please let us know if you have any other questions!

Thanks,
Dan

Hi @lucas-almeida_8120,

This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon.

Thanks,
Dan

Hi @jens-viebig_4541,

This is because you have not downloaded any versions of log4j-core as of yet. Once at least one version is downloaded, it will become auto-assessed after the next vulnerability database update. This situation is something that is being addressed with the upcoming release of ProGet 2026.

Thanks,
Dan

Hi @geraldizo_0690,

Thanks for sending that over. Can you also send me the details for your Blocked assessment type? You can get those by navigating to Administration -> Vulnerabilities and Assessment Types and then click on the Blocked assessment type. I just want to confirm those settings first.

Thanks,
Dan

Hi @parthu-reddy,

Sorry for the delayed response. When you navigate to an image that was being kept (one of the latest 20), do you see a sub-images tab on it? I'm thinking the retention rule deleted the parent (Fat Manifest), but not the sub-images.

Thanks,
Dan

Hi @christian-georg_5533,

Would you be able to provide us with an example SBOM file that we can test with?

Thanks,
Dan

Hi @geraldizo_0690,

Can you please provide which version of ProGet you are using that has this issue?

Thanks,
Dan

Hi @gbeckett,

Thanks for sending that screenshot. It is not what I expected to see, but I can see why that issue is happening now.

I have created ticket PG-3234 to fix this issue. It will be released this Friday in ProGet 2025.23.

Thanks,
Dan

Hi @gbeckett,

Would you be able to provide us with a screenshot of the manage credentials page? https://proget.***REDACTED***.services/administration/credentials?showFeedImportServicesOnly=True

I think I see what could cause this error, but it would help us to pinpoint the issue.

Thanks,
Dan

Hi @sirko_6724,

I now understand what you mean by our search pattern for a users' groups. ProGet does this in an attempt to reduce LDAP calls since we do not synchronize users and groups to ProGet. This allows us to make 1 LDAP call to get the groups. If we searched by user, we would then have to make a call to get the user and then X number of calls to load each group's details.

Based on OpenLDAP's documentation, groups will include one or more member attributes. Based on the record you sent me, that may not be the case for you. Is it possible for you to add that to your directory?

Thanks,
Dan

Hi @sirko_6724,

Which OpenLDAP-based server are you currently using? We have seen that most OpenLDAP-based servers tend to use different attributes based on their configuration. By default we use the values suggested by OpenLdap, but you may need to modify them to suite your setup. With that said, ProGet looks up both ways; get groups from the user and get users for the group. In most operations, ProGet will first find the user, then load their groups, and then check if the user or user's groups for permissions.

Typically the starting point is verify the LDAP attributes and queries are correct for your OpenLDAP based server. Can you also share what you have configured for your LDAP attributes and LDAP queries?

Thanks,
Dan

Hi @Sigve-opedal_6476,

I just tested with a 3GB .iso file and could upload without issue. When you tested locally on the same workstation, did you use http://localhost or the normal URL? Chances are the normal URL will still go through the firewall, even when on the same workstation. I would check in with your IT team and see if they are blocking .iso upload files to your ProGet instance.

Thanks,
Dan