Nice idea! That was pretty trivial to add in there, and will be in the next maintenance release via PG-3038: [image: 1751500114153-0862e122-a88d-49ef-ad76-204f40afaec5-image.png]

Hi @michal-roszak_0767 , That looks like it's just a "web page" with a bunch of links to files? ProGet does not support connecting to "web pages" and we have no plans to add that feature. There's simply no API to use, which users could never be able to "see" the files in ProGet until after they've been downloaded -- and the lack of metadata also creates all sorts of other complexities. However, you can create an asset directory to store "generic" files. It's basically a web-based file system: https://docs.inedo.com/docs/proget/asset-directories-file-storage/what-is-an-asset-directory Thanks, Steve

@mmaharjan_0067 we'll see how we can improve this while we work on PG-3034

Hi @mmaharjan_0067 , This is definitely some kind of UI regression; we did a lot of code-cleanup / refactoring on the front-end pages. We'll get this fixed via PG-3034 in an upcoming maintenance release (targeting next week's 2025.4). Thanks, Steve

@stevedennis The backup job in proget:25.0.3-ci.3 works as expected, thank you!

Hi Steve, thank you! I will try badssl.com out and see how ProGet reacts. Thank you again, Stefan

That's the intended/expected behavior of repackage. The use case is CI/CD workflows, so you would do something like: Create w.x.y-ci.z Repackage to w.x.y-rc.z Repackage to w.x.y Retention policies would then clear out old -ci and -rc packages. I believe that display bug has been fixed in ProGet 2025; I remember seeing it listed as a bug discovered during testing. But in any case, it's in the package history as you can see.

Hi @mmaharjan_0067, This is not a trivial request and would require database changes, new API endpoints, and of course pgutil changes. We will put it on our ProGet 2026 roadmap for future consideration -- hopefully some other users will chime in! UPDATE (2026-May-14); this did not make our ProGet 2026 release (it's a fairly complicated/involved change), and we've decided to wait for other users to let us know if they'd like this or similar API changes. Thanks, Steve

Hi @michal-roszak_0767 , You can just click "edit" on an API Key in the UI to change the date or secret value. However, if you have "Cryptographic hashing" enabled, then you will need to delete the key and recreate it to change the value. Thanks, Steve

Hi, @rhessinger! Thank you for looking into this. I will do some retesting as soon as the 2025.2 is released. Thanks, Petter

Hi @mwatt_5816, Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday. Thanks, Rich

Hi @parthu-reddy , These indicate that your network stack is being overloaded. npm can do this, as it's sending thousands of simultaneous requests to your server. Each of these requests require multiple database connections (network) and requests to remote registries (network). If you're using load balancing, you'll want to tweak the configuration to do rate limiting. For example, in npm it's this: https://blog.nginx.org/blog/rate-limiting-nginx Hope that helps, Steve

Hi Marc, Thanks for the note! That file is actually a sort of cross-platform way of storing symbolic links. BuildMaster also includes all the binaries needed for agents on both Windows and Linux, including .net runtimes for all three. In order to save space we deduplicate identical binaries from the agents. We use a simple json file instead of proper symlinks because we use the same file on Windows/Linux and it's easier this way. All the paths in the file have historically used Windows path separators due to how we generate it, and we convert those in BuildMaster at runtime to the proper format.... or at least we were supposed to. At some point there was a regression added that caused this to not happen when updating from Linux. Anyway, this will be fixed as BM-3981 in the next release :)

Hi @jfullmer_7346, Thanks for the detailed recreation steps on this! I was able to recreate the issue and created a ticket, PG-3018, to track the fix. This is expected to be fixed in ProGet 2025.2 on Friday of this week. Thanks, Rich

Thanks @rhessinger, that clarifies things, and I can move on. Best regards, Stefan

Hi @lukas-christel_6718, Sorry for the delay on this. We just pushed an updated pgutil that will now skip over any invalid versions. Thanks, Rich

Hi @m-karing_2439, It looks like this is a network-related issue: "Cannot determine the frame size or a corrupted frame was received." There are no changes in ProGet 2025 that would cause something like this, but it's possible that a firewall or something else is interfering with the communication. The executable name changed from ProGet.Service.exe to proget.exe, and we've seen some "anti-virus" tools require a new execption be made. No idea why it would work for PyPi, however. Hope that at least points in the right direction. Thanks, Steve

Yes - they are "self-connectors". We've now bought an externally signed certificate, as it seemed like the simpler option (the in house cert option was causing other issues too). However that hasn't resolved the issue with the self-connectors. However, I've just edited those connectors manually to use http rather than https, and that has resolved the issue. But It's not really an ideal solution. So it looks like from inside the docker container it's still not "trusting" the externally signed certificate.

Hi @rel_0477, I just happen to check right when this came in. Glad to hear it is working again! Was it the local cache? Cargo has a pretty aggressive cache for both good and bad packages. Thanks, Rich

Hi @kc_2466 , The message "Feed-scoped Privileges are not available in ProGet Free Edition. You can still add them, but they will apply to all feeds." should be displayed when you add a privilege, but it's probably easy to miss. I'm not sure if we show it after that. As for Personal API Keys, you can create them as an admin, but non-admin users can't create their own. It's a different page. Cheers, Steve