Hi @caterina , First and foremost, Microsoft has effectively discontinued Windows Integrated Authentication (WIA) in favor of more modern and secure environments. As such, we strongly advise taking this opportunity to simply move away from it. Our recommended environment is: No authentication required to view/download packages the only exception to this is packages containing things like trade secrets. that should not be the default, as "when everything is secret nothing is" API Key required to publish packages minimal permissions (i.e. no overwrite) limit to feeds when appropriate, so you don't have too many keys consider rotating annually That said, WIA is still supported in the Integrated Web Server and unsupported feeds (like npm) are automatically excluded from WIA when Kestrel is used (i.e. when you are NOT doing port sharing, and binding to a port). You can also explicitly exclude NuGet feeds. However, it's not possible to do "authentication by port", like what was possible by creating two sites in IIS. Hope that helps, Steve

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

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

I've had a fair bit of success using copilot to reverse engineer a terraform provider, there are some gaps in what you can do in the UI vs what the api supports however. helm proget: image: tag: "25.0.25" replicaCount: 1 # Encryption key from pre-created secret existingEncryptionKeySecret: "proget-encryption-key" encryptionKeySecretKey: "encryption-key" # License key from pre-created secret existingLicenseSecret: "proget-license" licenseSecretKey: "license-key" resources: requests: cpu: "500m" memory: "1Gi" limits: cpu: "2" memory: "4Gi" podAnnotations: prometheus.io/scrape: "true" prometheus.io/port: "80" prometheus.io/path: "/health" database: type: "external-postgres" externalPostgres: existingSecret: "proget-db-credentials" secretKey: "connection-string" persistence: packages: size: "100Gi" storageClassName: "managed-csi-premium" accessMode: "ReadWriteOnce" backups: size: "50Gi" storageClassName: "managed-csi" accessMode: "ReadWriteOnce" service: type: ClusterIP ingress: enabled: false gateway: enabled: true parentRefs: - name: traefik-gateway namespace: traefik sectionName: https hostnames: - proget.demo Terraform # ────────────────────────────────────────────────────── ────────────────────────────────────────────────────── # Manages a NuGet feed backed by a filtered nuget.org # connector, an MIT license, CI/CD API keys, and basic # user/group permissions. # ────────────────────────────────────────────────────── terraform { required_providers { proget = { source = "mycompany/proget" } } } # ── Variables ──────────────────────────────────────── variable "proget_url" { description = "Base URL of the ProGet instance" type = string default = "https://proget.example.com" } variable "proget_api_key" { description = "System-level API key for the provider" type = string sensitive = true } # ── Provider ───────────────────────────────────────── provider "proget" { url = var.proget_url api_key = var.proget_api_key } # ── Connector: filtered nuget.org ──────────────────── resource "proget_connector" "nuget_org" { name = "nuget-org-filtered" url = "https://api.nuget.org/v3/index.json" feed_type = "nuget" timeout = 10 metadata_cache_enabled = true metadata_cache_minutes = 30 metadata_cache_count = 250 filters = [ "!*", # block everything by default "Microsoft.*", "System.*", "Newtonsoft.*", ] } # ── Feed: NuGet with retention ─────────────────────── resource "proget_feed" "nuget" { name = "nuget" feed_type = "nuget" active = true can_publish = true cache_connectors = true vulnerabilities_enabled = true licenses_enabled = true use_with_projects = true use_api_v3 = true connectors = [proget_connector.nuget_org.name] retention_rules_enabled = true retention_rule { keep_versions_count = 10 delete_prerelease_versions = true keep_used_within_days = 14 delete_cached = true } } # ── License ────────────────────────────────────────── resource "proget_license" "mit" { code = "MIT" title = "MIT License" urls = [ "opensource.org/licenses/MIT", "spdx.org/licenses/MIT.html", ] } # ── API Keys ───────────────────────────────────────── resource "proget_api_key" "admin" { type = "system" display_name = "Terraform-Admin" description = "Full control key used by Terraform" system_apis = ["full-control"] } resource "proget_api_key" "ci_readonly" { type = "feed" display_name = "CI-ReadOnly" description = "Read-only key for dotnet restore / npm install" feed = proget_feed.nuget.name package_permissions = ["view"] } # ── Group & User ───────────────────────────────────── resource "proget_group" "developers" { name = "Developers" } resource "proget_user" "alice" { name = "dev-alice" display_name = "Alice Developer" email = "alice@example.com" password = var.alice_password groups = [proget_group.developers.name] } variable "alice_password" { type = string sensitive = true } # ── Permissions ────────────────────────────────────── resource "proget_permission" "devs_view" { user = proget_user.alice.name task = "View & Download Packages" deny = false } resource "proget_permission" "devs_manage_nuget" { user = proget_user.alice.name feed = proget_feed.nuget.name task = "Manage Feed" deny = false } # ── Outputs ────────────────────────────────────────── output "nuget_feed_url" { value = "${var.proget_url}/nuget/${proget_feed.nuget.name}/v3/index.json" } output "ci_api_key" { value = proget_api_key.ci_readonly.key sensitive = true } Still a work in progress and not shareable but you get the idea of what could be possible