@atripp thanks for confirming

@Alex_9348 found them! https://s3.amazonaws.com/cdn.inedo.com/release/rules.pdf Enjoy :)

@atripp Ohh, sorry my mistake, changed it to proget, same problem actually. Will check at our end.

@atripp Thanks

@stevedennis I swtiched from "V3: Active Directory (LDAP)" to "V4: Active Directory/LDAP (Preview)" and all is good now. Logon went from two/three minutes down to one second.

Hi @Darren-Gipson_6156, No problem! Glad it is working. ProGet 2024.6 will include a fix for this issue, PG-2695. So hopefully this won't happen again! Thanks, Rich

I have done more digging and you are right. My windows service wasn't actually pointing to the exe that was updated If i run the updated service, funnily enough it works!

In that case please just upgrade and it should be resolved :)

Hi @rick-kramer_9238, You could do this via the API; it would involve first Querying Package Versions, and then for each version returned, Setting Package Status. I think it'd be a "relatively easy" script to write - so if you create one that can do it, please share :) Hope that helps, Alana

Hi @forbzie22_0253 , This refers to Delete Package, which was introduced in ProGet 2023: https://docs.inedo.com/docs/proget-api-packages-delete We don't really document/track what Native APIs change between releases, so I'm not really sure: https://docs.inedo.com/docs/proget-api-http#native-api-endpoints You can do a comparison in the /api/reference page. Thanks, Alana

@atripp I thought the fix was for Otter !

@atripp Thank you for your time and the fix. I can wait for the next release. Best regards PhilippeC.

@atripp Thanks for the update

Hi @gdivis, pgutil packages delete --source=scati --feed=stable --package="pacomalarmprocessor" --version=7.2.1.0-1 --qualifier="arch=amd64&component=scati&distro=bionic" It works perfect with that command. Thank you. Keep up the good work.

Hi @artur-wisniowski_4029, We'll get this fixed, but it's unlikely to be in this week's release. ProGet hashs the complete package file for every package uploaded to it, while the APK spec says to hash only over a certain tar segment of the package. We've been returning ProGet's hash of the package file as the checksum and this is incorrect as you've noted. We'll post here again when we have a fix date, but I'd expect it will be either next week or the week after. Thanks!

Hi @pawel-ostrowski_5669 , ProGet dynamically generates these indexes based on an aggregation of locally stored packages and connector results on each request, so caching doesn't make a lot of sense. npmjs.org, on the other hand, needs to only update indexes when a new version is uploaded, so the cache duration can be a long time. Thanks, Steve

Hi @pbinnell_2355 , It looks like you have Windows Integrated Authentication enabled. Curl does not support this, but with powerShell you would need to add -UseDefaultCredentials Thanks, Steve

Hi @am-infrastruktur_3111 , Chocolatey packages are scanned for viruses, so you will see those pop up. For example, pathdebug 0.3.4 should show up in ProGet's vulnerability system: https://security.inedo.com/vulnerability/details/PGV-2420934 Otherwise, there is unfortunately no standardized/consistent naming for Windows software (unlike APK, APT, RPM, etc), so there's no way to associate a vulnerability report like CVE-2024-21392 with a software package. In this case, Microsoft calls the effected software ".NET 8.0", not .NET or dotnet, etc. In Other reports, they call it ".NET8", etc. And you can see that it translates a little weird n the CVE report as well: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21392 ".NET 8.0 affected from 1.0.0 before 8.0.3 " - weird, right? This is a known issue in the industry for many years, and it would need to be address by Microsoft first. It's sadly not on their priority list. Best, Alana

Ultimately this is going to involve training for your developers. Just like instituting a code review process will be new and uncomfortable at first, a package review process will be the same. Developers will not like it and they will complain. However, 99% of the time, developers will be fine using the approved feed. 1% of the time (when they want to test a new package or upgrade), then will use the unapproved feed. They'll just need to learn how to switch package sources (it's a drop-down in Visual Studio) and then learn not commit commit these package references. My advise is to make it incumbent upon developers to not commit code/configuration that depends on unapproved packages. If they do, then it will "break the build" because the packages aren't available. This is an expected behavior - it would be like if a developer decided to upgrade to .NET9-beta. "Don't break the build" is a common mantra on development teams, and it means developers can't commit code changes that will do that. Just extend that to using unapproved packages.

Fix verified on 2024.2 version. Thank you.