Hi @cole-brand_2889, I have identified the issue, PG-3268, and this should now be fixed in ProGet 2025.27. Please upgrade to 2025.27 and see if that resolves your issue. Thanks, Rich

The reason I'm using Docker.Desktop is not to run Linux on Windows but to run Docker. The goal was to mimic our dev and prod deployment which involves using helm files to update what version of a given image is deployed in a given environment. This part I have working. I just figured I'd try taking advantage of having docker installed to try out this feature of BuildMaster. I didn't expect it to be this troublesome though. When I was working on it this morning I tried updating the tag to pull a specific version of the image to ensure it was Linux but that didn't work either. In fact it didn't change anything. I'll look at it again on Monday. Maybe someone will have some insight before then and help me out. Let me know if there is anything I add to the post to help. If I see a response over the weekend I'll definitely update the post with any requested information.

oh, and I will look up this docker run command. Unfortunately that doesn't allow me to use the built in test function in BuildMaster which could take away from part of my sales pitch. We'll see what I can do, and maybe you or someone else will think of something else.

Thanks for sharing all the details @sgardj_2482. You shouldn't need to modify the Embedded Database like this when using a GMSA. It should continue to work just fine using a username/password as configured. If you ran into an issue when changing the service account, please let us know. Note that we don't support modifying the Embedded Database like this, so please be aware this may suddenly break in a future upgrade.

Hi @certificatemanager_4002 , This is really easy to do in ProGet and no need for a "scan". I can't even imagine how such a "scan" could work. Anyway, you just simply need to add a connector filter that prefixes your internal packages. For example, our filter for NuGet packages would look like Inedo* - which prevents any package named that coming through a connector. Check out this article to get some more details: https://blog.inedo.com/software-supply-chain-security/three-things Thanks, Steve

Hi @daniel-mccoy_4395 , About the only way I can imagine that happening is if you delete the version from the feed and navigate to that page. Or, if it was a remote package, and somehow the connector stopped working between pages. I would try to find a pattern and see if you can reproduce this more consistently. Thanks, Steve

Yes, you're right. I cleared the cache with nuget locals all -clear, after which I could no longer install the same package via Visual Studio or the command line. Thank you for pointing this out to me.

Hi @carl-westman_8110 , Not really... Feeds and Views are a bit different concept and we don't really encourage using the presence in a particular feed as a means to identify whether something has been released. Instead, we'd encourage using Pre-Release Packages & Repackaging , which make it obvious from simply lookin at the version (i.e. 1.1.1-rc.7 indicates not yet released). Thanks, Alana

Hi @certificatemanager_4002 , ProGet is licensed per instance (i.e. installation), you will need a separate license if you wish to maintain a production and non-production instances of ProGet. See the official Licenses for Non-production / Testing Environments for more details. For things like a one-off, cloud-migration, using a Trial license (which you can get from My.Inedo.com) is fine. Thanks, Alana

Thanks! No immediate rush, I'll wait for mainline release :) Best regards Nils Nilsson

Hi Alana, thank you for your reply

@rhessinger Thanks for the response. I am using mcr.microsoft.com/mssql/server:2025-CU2-ubuntu-24.04 as the container image.

Hi, i had already downloaded log4j-core with the "bad" version. I would have expected this to be an immediate action but as you described it is tied to a scheduled job triggered by vulnerability update. Looking at the feed and packages today shows me that the auto assessment of all the downloaded packages was done overnight. But does this mean the auto-blocking will never work the first time a package is downloaded? The auto blocking will always only kick in after the next vulnerability update ?? I hope that logic does not apply to the malicious package blocking as well...

Hi @kien-buit_2449, This is partially fixed in our vulnerability aggregator. You should see alpine vulnerabilities showing up next time your vulnerability updated runs. I also recreated a situation where certain packages may not be removed upon update of the vulnerability. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27. Thanks, Rich

Hi @stno_9153 , Oh yeah, that'll make a HUGE difference for public repositories. OTherwise it'll probably not work at all :) Anyway glad it's working now Thanks, Alana

Hi @brandon_owensby_2976, Argo CD is free / open source and no license is required. You'd be better off learning that than trying to do Kubernetes another way. FYI there's also Kargo, which is a "wrapper" that sits on top of ArgoCD and has some kind of promotion workflow outside of typical GitOps (pull requests I guess?). To be honest, I really don't know if the Kubernetes extension even works; it was originally intended for Otter, to create a "Desired state" and offer an alternative to Git-based approaches. But there's just no demand and GitOps is just the Kubeernetes standard. We haven't tested it in years. We do not plan on migrating it to the next SDK version. It's just a light wrapper around kubectrl, which has probably changed over the years. If you really wanna mess with Kubernetes outside of Argo CD I would just run kubectrl apply/replace directly. Good luck!!

Hi @christian-georg_5533 , Thanks for sharing the additional context, that makes sense. You are correct -- ProGet is a package repository with SCA as a value-added feature. Most of our users create SBOM because they are required to due to regulations, and but don't find much use outside of that :) Of course we're always interested in expanding features but we aren't really striving for the "central SBOM Repository" use case now. We'll see if there's more demand down the line, feel free to share more information (other products, tools) sinc eit's always good to think about future versions of the product! Cheers, Alana

Hi @parthu-reddy , This does not appear to be a "fat manifest". Two other things are coming to mind. First, are these referenced in any helm charts? If so, they won't get removed unless you delete the helm chart first. Second, how about trying a separate policy, "Delete untagged manifests"? That should clear out these images. Thanks, Alana

Hi @cole-brand_2889 , Wow, I didn't realize that S3 rate-limited like that!! That's good to know. Unless this is something that could be configured as an advanced SDK switch in the S3FileSystem, then I don't think there's much that could/should be done in the ProGet or extension code. After searching the error (and seeing this very post on the first page of Google ), this just seems to be endemic with S3; there's no published rate limit, and even in AWS official blog article the only solutions seem to be "follow the error message and reduce your request rate". There's probably something you can do do on the load-balancer side of things... reducing concurrent requests, etc. Let us know what you find! Thanks, Alana

Hi @davidroberts63 , While connector filters were never really designed to replace the "approved packages" workflow, we've seen many users do exactly that over the years, yielding hundreds of entries. It's not exactly a use case we recommend, as one of the big benefits of the approved packages flow is to prevent "instinctively upgrading dependencies" yielding in regressions. But, if you're already effectively doing that through automation, then I suppose you already know the risks :) From a performance standpoint, it shouldn't make a notable impact. Those have been optimized for quite some time now. Thanks, Alana