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

Fix verified on 2024.2 version. Thank you.

Hi @pbinnell_2355, Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil Hope this help! -Greg

@rick-edwards_9161 that is correct, these will only be developed for ProGet 2024

I set our metadata caching to 10000 queries over 24 hours. I will reduce to the default first and monitor. Thanks Dean

Hi Dean Thank you This is helpfull. I will dig a little bit and let you know if I found something. Best regards PhilippeC.

@jw we'll definitely keep this in mind, it doesn't look trivial based on our usage of that marked library Personally, I always try to keep the Diagnostic Center clean and empty, so when new issues show up I can easily spot and address them. Sifting through messages that are basically spam, without being able to filter or ignore them costs me more of my time that I would like to invest for monitoring. We do not recommend using the Diagnostic Center for proactive monitoring. It's only intended as a tool for troubleshooting things like connector or 500 errors that you / end-users encounter. There are a lot of non-problem errors and warnings logged that aren't worth time even looking at.

Makes sense, thanks for the quick fix. Cheers

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)

Maybe I'm getting old and 14px seemed to small In addition, we don't display a lot of textual information so the larger font size seemed to fill out the whitespace nicer, particularly in tables (which there are a lot). I was never really all that happy with how this filled out whitespace (from ProGet 2023): [image: 1714496162493-5e3d33ea-33a0-40ed-9391-667a1aa74c60-image.png] I'm not thrilled about ProGet 2024, but it felt like an improvement... and most importantly, "something different" than past few years: [image: 1714496179530-07c12e78-8715-4620-acdd-d9fac38b564e-image.png] That said, for ProGet 2025 I'd love to do a much more notable style refresh (logos? etc?), perhaps even some navigation tweaks. So open to ideas there

Hi @rmusick_7875, I'm afraid API endpoints are not customizable and we do not support doing "reverse proxy" or otherwise rewriting the URLs. Hopefully this will be a good chance to make the endpoint-url more easy to configure/change - this will be important, as you may wish to move to multiple feeds, etc. Good luck, Steve

Hi @greg-swiderski_0221 , It looks like there is an "Object reference not set to an instance of an object" error that's occurring while trying to connect: 2024-04-30 09:52:41,341 8256 [WARN ] - Unable to connect to source 'http://localhost:8624/nuget/approved-choco/': Object reference not set to an instance of an object. That error is presumably occurring from the Chocolatey client (choco), and unfortunately there's no way to know what it means. Most likely, it's an "error reporting an error" message, but it's hard to say. You could use some HTTP monitoring software (Fiddler Classic, Wireshark), and see if ProGet is returning an error of some kind.... but even if so, choco should report that error. I would check with the chocolatey team on this one. Thanks, Steve