Hi @joris-guex,

I took a look at the ProGet change and talked with a couple of other Engineers and it looks like the issue is that the lobssh2-sys package is not included the version requirement on a dependency. According to cargo's specifications, the version specification is required. We are guessing that crates.io is handling the issue (whether it is a missing version or extra whitespace included in the manifest) and outputting it in a way it works with the cargo client. Could you please provide us with an example Cargo.toml that can recreate the build issues? This will allow us to implement a better solution to this issue.

Thanks,
Dan

Hi @cssccmgroup_4090,

I created a private ticket on your behalf. You can see it by navigating to https://my.inedo.com/tickets. Please upload the SBOM through that ticket.

Thanks,
Dan

Hi @cssccmgroup_4090,

Thanks for sending over this detail!

For Issue 1: We were able to reproduce this and will have it fixed in PG-3292 in today's release of ProGet 2026.2.

For Issue 2: We see the issue with the vulnerabilities array and will also have that fixed in today's release of ProGet 2026.2 (tacked in fix PG-3293). We are having some issues recreating the issue with the complainace.detail. Would you be able to send us an example SBOM file with this issue?

Thanks,
Dan

Hi @Ashley,

Glad to hear that fixed the issue with the Project Name!

You are partially right on the noncompliance. The publish date is definitely causing most of the packages to be noncompliant. Based on your logs, I'm also seeing at least one deprecated package as well.

I see you already have another forums post about the recently published issue. I believe we can continue that issue there and close this one out.

Thanks,
Dan

Hi @Ashley,

I took a look into this error, and the constraint that is failing only checks for the Project_Name to not be an empty string. Based on your pgutil command, I'm guessing $ProjectName is set to null or an empty string. Can you verify that $ProjectName is not null, empty, or whitespace?

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

Hi @it_9582,

You are receiving this error because the filename length is limited to 200 characters for Assets. Yours is 201 characters long. I have added a ticket, PG-3197, to show a better error message when the file name is too long. If you horten your filename by 1 character, you should be able to upload the file.

Thanks,
Dan

Hi @dafex36959_6595,

Based on the exceptions, this is most likely due to an invalid character in the display name field or in an associated group. This is due to a bug that is buried in a third-party library that is based on another library that is based on an some RFC standard.... but who knows. It's been a known issue for years, and presumably end-users of this library (it's the #1 library for LDAP on .NET) have simply worked-around the issue by not using those characters in domains, groups, etc. I'm afraid it's just not something we are able to fix.

We really hate giving this response, but we also cannot go down the rabbit hole of trying to fix the library to support this edge case -- Unfortunately, this is a "limitation" of our software and recommend working around the issue by either removing the unescapable character (typically a '# or a ',') or try using ADv4 and override the display name to use a different field and/or group discovery.

Thanks,
Dan

Hi @Sigve-opedal_6476,

A 104 Socket Exception typically means that a firewall is blocking the upload of the file. Do you have a firewall sitting between your browser and your ProGet server?

Thanks,
Dan

Hi @MellowOak,

A quick background on how ProGet handles malicious packages. Malicious packages are treated as vulnerabilities in ProGet. That means that a malicious package will show up as an unassessed vulnerability (since they rarely have a CVSS score) and can be assessed, analyzed, and blocked like any other package with a vulnerability. With that said, most of the time, this blocking is not needed because as soon as they are identified as a malicious package, the public feed will have already removed the package. The only time they are really caught in ProGet is when they have already been downloaded and cached. In ProGet 2026, we are working on a better way to store and distinguish malicious packages separate from vulnerabilities.

To answer your questions:

1. All paid editions support the ability to block malicious packages via policies. Please refer to our License Restrictions documentation for edition limitations.
2. The best configuration for blocking malicious packages is to block all unassessed vulnerabilities. This requires an administrator to review unassessed vulnerabilities regularly on the Reporting & SCA -> Vulnerabilities tab.
3. Yes a block can be overriden by:
   1. Add an exception in the policy for that package and version
   2. A ProGet admin can set the package status to Always Allow
   3. It could be manually downloaded from the ProGet UI
4. Inedo's aggregator runs mutliple times a day to pull from all the vulnerability and malicious package sources and creates a custom compresssed database file. As long as ProGet has access to cdn.inedo.com, ProGet will then download that file nightly update it's database. It can be updated under Scheduled Jobs -> Vulnerability Database Updater.
5. There are multiple ways to gain visibility, but the easiest is to use ProGet's notifier feature to be alerted when a vulnerability to a pacakge.

Hope that helps to answer your questions! Please let us know if you have any other questions.

Thanks,
Dan

Hi @misael-esperanzate_7550,

What version of ProGet do you have installed? This may be an issue that we have already fixed. I remember this happening in some older versions of ProGet.

Thanks,
Dan