Hi @dean-houston, thank you for the explanation. I understand, that you don't want to risk the implementation for these special version numbers. On dealing with these false positives, it would be great to ignore a vulnerability just for a specific version, therefore fixing just the version mismatch, rather than deactivating the vulnerability globally. But I'll gladly wait for ProGet 2026 and check out the changes done to the CV management. Best regards

Hi @Ashley , It sounds like you're definitely looking in the right place / setting the right configuration. X-Forwarded-For should do the trick, but something as silly as a typo (which I've done several times) will make it not work. Here are the settings we recommend: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Port $server_port; And as an FYI, here is the code we use to get the ClientIP adddress. public static string GetClientIPAddress(this AhHttpRequest request) { ArgumentNullException.ThrowIfNull(request); var forwardedFor = request.Headers["X-Forwarded-For"]; if (!string.IsNullOrWhiteSpace(forwardedFor)) { var ips = forwardedFor.Split(','); var clientIp = ips.FirstOrDefault(); if (!string.IsNullOrWhiteSpace(clientIp)) return stripIpv4OverIpv6(clientIp.Trim().Truncate(50)!); } return stripIpv4OverIpv6((request.NativeRequest?.HttpContext?.Connection?.RemoteIpAddress?.ToString() ?? request.UserHostAddress).Truncate(50)!); static string stripIpv4OverIpv6(string ip) { if (ip.StartsWith("::ffff:") && ip.Contains('.')) return ip["::ffff:".Length..]; return ip; } } Although I think the stripIpv4OverIpv6 bits may be relatively new. Thanks, Alana

Hi @ybaskar-temp_3339 , The "root cause" is relatively easy to answer. The error was occurring on the 10. Block 6.2 Upgrades.sql script, which is simply this: IF OBJECT_ID('ActionGroups') IS NOT NULL EXEC sp_executesql N' IF NOT EXISTS(SELECT * FROM [Configuration] WHERE [Key_Name] = ''Legacy.NoLegacyFeaturesDetected'' AND [Value_Text] = ''True'') RAISERROR(''Cannot upgrade to BuildMaster 6.2 unless "Legacy.NoLegacyFeaturesDetected" in Advanced Settings is "True". This can be done by running the legacy features checker.'', 16, 1) ' Basically it will simply crash unless Legacy.NoLegacyFeaturesDetected is not set to "True". The "Legacy Feature detector" should have set that to "True" if there were no legacy features detected... but perhaps it didn't? Since you were able to bypass it, I wouldn't worry about it. In the "worse case", legacy data would have been purged during the delete. Thanks, Alana

Thanks @atripp, that makes sense. I was having another issue with pgutil which turned out to be my fault, however I believe there is a follow on issue to do with the compliance analysis for project builds that have yet to have been pulled to ProGet. More detail on my original post here: https://forums.inedo.com/topic/5733/proget-unable-to-publish-sbom-from-pgutil/4. @Dan_Woolf suggested continuing the topic here as it's related to non-compliant packages and what I believe to be the recently published rule. Is this something you can take a look at? Thanks!

Hi @Ashley, Glad to hear that fixed the issue with the Project Name! You are partially right on the noncompliance. The publish date is definitely causing most of the packages to be noncompliant. Based on your logs, I'm also seeing at least one deprecated package as well. I see you already have another forums post about the recently published issue. I believe we can continue that issue there and close this one out. Thanks, Dan

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