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 @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

Hi @michal-roszak_0767,

That icon indicates it's a remote package. That means it can be remote or cached. If you use the Pull to ProGet feature, then it will pull all the files locally and converts them to an internal/local package and those icons go away. If you combine that icon with the error "File not found on disk", this means the artifact was cached, but something deleted the file from disk. That is what Dean was trying to explain.

@misael-esperanzate_5668,

I think the next step from here is to navigate to Manage Feed -> Storage & Retention, and then run the re-index feed job (found to the right of storage) with the "Remove database entries for missing package files" option selected. That will remove any Maven artifacts from the database that are missing local files and allow them to be re-cached again. If you want to review the Maven artifacts that would be removed, run the re-index without selecting the remove database entries option. This will warn you of any Maven artifacts that a missing first, then you can run it again to remove them. Hope this helps!

Thanks,
Dan

Hi @lukas-christel_6718,

You mentioned that your version had an underscore in it, but the command you referenced does not have an underscore. Is this something that once you add a package with a bad version, then any package fails to install, any version of a package with the same group and name fails to install, or just the specific package with the bad version fails to install? Also, can you please send us the bad version that you uploaded to the feed? Once we have that information, we should be able to reproduce your issue and get a fix out for you.

Thanks,
Dan

Hi @si-peham_2672,

As far as I can tell, it looks like there is still a permission issue with the working directory that is preventing file listing. The workaround to use the --input argument seems to get past that issue, so I would continue to use that. For your reference, I did test this locally and on a test server, and both worked without issue. If you are interested, here is a link to our code that is searching for the file (https://github.com/Inedo/pgutil/blob/5001174a4c786bb238e8546d18d82fed71cfcc58/Inedo.ProGet/Scan/DependencyScanner.cs#L114). The SourceFileSystem.Default.FindFilesAsync just calls new DirectoryInfo(folder).EnumerateFiles and then matches against the name.

For the Specified argument was out of the range of valid values error, that will be resolved in ProGet 2024.33, which will be released this Friday.

If you have any other questions, please let us know.

Thanks,
Dan

Hi @si-peham_2672,

I think this is related to a recent Audit API bug, PG-2941. We will be releasing that fix in ProGet 2024.33 due out on Friday. Can you please try running that with the --noaudit parameter? That will bypass the audit portion in the scan. That will at least scan the "requirements.txt" file and create the build, then the audit will then be performed later by ProGet.

Thanks,
Dan