Investigating myself, I stumbled over one significant change in the new container: The owner of the hierarchy in /var/proget/database has changed in the updated container: Old (2026.14): root@proget:/usr/local/proget# ls -la /var/proget/database/ total 160 drwx------. 20 postgres root 4096 Nov 15 09:11 . drwxr-xr-t. 8 root root 94 Nov 15 09:11 .. -rw-r--r--. 1 root root 98 Jun 21 2025 .pgsqlconn -rw-------. 1 postgres 104 3 Jun 21 2025 PG_VERSION drwx------. 7 postgres 104 4096 Aug 20 2025 base -rw-------. 1 postgres postgres 44 Nov 15 09:11 current_logfiles drwx------. 2 postgres 104 16384 Nov 15 09:11 global drwx------. 2 postgres postgres 12288 Nov 15 09:11 log drwx------. 2 postgres 104 4096 Jun 21 2025 pg_commit_ts drwx------. 2 postgres 104 4096 Jun 21 2025 pg_dynshmem -rw-------. 1 postgres 104 206 Aug 29 2025 pg_hba.conf -rw-------. 1 postgres 104 2640 Jun 21 2025 pg_ident.conf drwx------. 4 postgres 104 4096 Nov 15 12:46 pg_logical drwx------. 4 postgres 104 4096 Jun 21 2025 pg_multixact drwx------. 2 postgres 104 4096 Jun 21 2025 pg_notify drwx------. 2 postgres 104 4096 Jun 21 2025 pg_replslot drwx------. 2 postgres 104 4096 Jun 21 2025 pg_serial drwx------. 2 postgres 104 4096 Jun 21 2025 pg_snapshots drwx------. 2 postgres 104 4096 Nov 15 09:11 pg_stat drwx------. 2 postgres 104 4096 Jun 21 2025 pg_stat_tmp drwx------. 2 postgres 104 4096 Nov 15 00:50 pg_subtrans drwx------. 2 postgres 104 4096 Jun 21 2025 pg_tblspc drwx------. 2 postgres 104 4096 Jun 21 2025 pg_twophase drwx------. 4 postgres 104 4096 Nov 15 09:17 pg_wal drwx------. 2 postgres 104 4096 Oct 5 10:51 pg_xact -rw-------. 1 postgres 104 88 Jun 21 2025 postgresql.auto.conf -rw-------. 1 postgres 104 30875 Jul 31 14:28 postgresql.conf -rw-------. 1 postgres 104 64 Nov 15 09:11 postmaster.opts -rw-------. 1 postgres postgres 100 Nov 15 09:11 postmaster.pid New (2026.15): root@proget:/usr/local/proget# ls -la /var/proget/database/ total 68 drwx------. 20 101 root 4096 Nov 15 11:47 . drwxr-xr-t. 8 root root 94 Nov 15 11:47 .. -rw-r--r--. 1 root root 98 Nov 15 11:18 .pgsqlconn -rw-------. 1 101 103 3 Nov 15 11:18 PG_VERSION drwx------. 6 101 103 46 Nov 15 11:18 base -rw-------. 1 101 103 44 Nov 15 11:18 current_logfiles drwx------. 2 101 103 4096 Nov 15 11:22 global drwx------. 2 101 103 46 Nov 15 11:18 log drwx------. 2 101 103 6 Nov 15 11:18 pg_commit_ts drwx------. 2 101 103 6 Nov 15 11:18 pg_dynshmem -rw-------. 1 101 103 206 Nov 15 11:18 pg_hba.conf -rw-------. 1 101 103 2640 Nov 15 11:18 pg_ident.conf drwx------. 4 101 103 68 Nov 15 11:32 pg_logical drwx------. 4 101 103 36 Nov 15 11:18 pg_multixact drwx------. 2 101 103 6 Nov 15 11:18 pg_notify drwx------. 2 101 103 6 Nov 15 11:18 pg_replslot drwx------. 2 101 103 6 Nov 15 11:18 pg_serial drwx------. 2 101 103 6 Nov 15 11:18 pg_snapshots drwx------. 2 101 103 25 Nov 15 11:32 pg_stat drwx------. 2 101 103 6 Nov 15 11:18 pg_stat_tmp drwx------. 2 101 103 18 Nov 15 11:18 pg_subtrans drwx------. 2 101 103 6 Nov 15 11:18 pg_tblspc drwx------. 2 101 103 6 Nov 15 11:18 pg_twophase drwx------. 4 101 103 109 Nov 15 11:27 pg_wal drwx------. 2 101 103 18 Nov 15 11:18 pg_xact -rw-------. 1 101 103 88 Nov 15 11:18 postgresql.auto.conf -rw-------. 1 101 103 31163 Nov 15 11:18 postgresql.conf -rw-------. 1 101 103 64 Nov 15 11:18 postmaster.opts Note: the uid:gid of the postgres user has changed from 101:103 to 994:994 Attempt to show this in a code snippet was denied for security reasons by the forum. Apparently just mentioning the files path in /etc/ that stores these values, triggers a security alert of the forum so I had to obfuscate it a little bit: Old: root@proget:/usr/local/proget# grep postgres /etc/p*wd postgres:x:101:103:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash New: grep postgres /etc/p*wd postgres:x:994:994:PostgreSQL administrator:/var/lib/postgresql:/bin/bash And success after manually updating the owner in the container. I just ran the following inside the container: chown -R postgres /var/proget/database After a container restart, it worked again. => I vaguely remember from the early releases with embedded postgres, that there was some permission problem too. So: problem found - fix pending (i hope ) Cheers -Fritz

Hi @rhessinger, I used postman to test the token and it appeared to give me repo info. Based on my research it looked like it was potentially due to the fact that it is a personal account rather than an enterprise one and the API for github works differently between those two. I wasn't sure if your plugin only worked for enterprise. I tried some workarounds it suggested (basically manually typing in the repo) and that didn't work either. I didn't see any entries in the diagnostic center. As far as the scopes, I have repo and everything underneath checked. I even added read:project. Also this is a classic token, Thank you, Brandon

Hi @wechselberg.nisboerge_3629 , It looks like the query is timing out after about thirty seconds. Does that line up with what you've seen? It starts deleting, and then fails? Are there a lot of assets in the directory? It could just be a bug/issue with the deletion code for large asset repositories. Thanks, Alana

Hi @bobmaurer , There are a couple ways to handle this: Overriding the Assessment on the vulnerability; this is probably the best way to do it Override the Compliance status on the package itself by doing Set Package Status But if it's temporary, then it doesn't really matter. They will both work. Thanks, Alana

@atripp small follow-up, I asked our platform team for some help investigating on their end, they observed the issue from the S3 side: Between 13:40:50 and 13:41:07 UTC, 16 multipart UploadPart PUTs from ProGet ([redacted]) to [redacted]/ghcr-proxy/blobs/... returned HTTP 400. The 400s came from our ingress-nginx, not [S3 solution]. [S3 solution] has no record of them. The requests never reached an upstream, and the bodies were shorter than a full ~5.25 MB part, for example 0.45, 2.0 and 3.2 MB. That is what nginx usually logs when the client closes the connection partway through sending the body. Four uploads were hit at about the same moment, and most failed parts succeeded on retry. One didn’t: sha256:266ebec216df42de9ed7c4d07422168f3329eecf923306036386404f10c5a0f8. Part 2 failed three times with no success after. ProGet still sent CompleteMultipartUpload at 13:40:53 and [S3 solution] returned 200. [S3 solution] accepts a completion that omits a part. I expect that object is missing part 2, which would explain the truncated blob.

Hi @clsa , Thanks for clarifying that -- I was looking to update the documentation and wanted to share my understanding to see if you had more insight here. It seems like this limitation applies to .pfx files but not .pem files. If we convert the pfx to a pem, it seems to work. Have you tried using --store pemfiles with WinACME instead? I'm thinking we can just note this and recommend using pem files instead. Thanks, Alana

@stevedennis Hello Steve. You don't need to remediate this, it's easy enough to work around. Best regards, Nils Nilsson

@dean-houston any chance I could suggest the same be done/added for other feed types & connectors? Options that show up under "Advanced" for connector configuration (e.g., Python feed's "simple" toggle, or library toggle for Docker), and e.g., the per-feed Settings panes (e.g., Docker Settings, NuGet settings). All our use cases have involved tweaking one of these settings, so it's a bit unfortunate to have gotten so close to the finish line in automation!

Here too, thanks for the quick fix :-)

Hi @sebastian.heess , Thanks for sharing all of the details; it looks like this is a regression in ProGet 2026.14; we'll get this fixed via PG-3419 in ProGet 2026.15. -- Dean

@stevedennis have created an internal support ticket EDO-13253. Have attached relevant output from syft/grype tooling.

Hi @m.u, We've actually found and fixed that connection leak internally this week. It's logged as PG-4026 and we are including the fix in BuildMaster 2026.3 tomorrow. I've logged the issue with the Native API as PG-4027, and it looks to be a trivial fix that we can also get in tomorrow's release, but I will let you know if it ends up taking longer. Thanks for reporting the issues! -Greg

@stevedennis thanks, that did the trick! I

Hi @abhijeet.patil, As an FYI, we do not recommend using an external PostgreSQL server. While it's technically possible to connect to an external PostgreSQL, we strongly advise against doing so. Not only does it require sufficient expertise in managing PostgreSQL servers and databases, but it generally has a negative impact on performance, increases the cost/complexity of your configuration, and leads to increased downtime. You may also receive reduced support since we will not support most PostgreSQL-related issues when you're using an external server, including unique permission configurations, database monitoring agents, transaction replication, etc. That said, this is exactly one of those scenarios we do not support (i.e. running commands like CREATE SCHEMA proget AUTHORIZATION proget). We're also not sure how to "fix" your database at this point, so hopefully it's something you can just recreate without running that command at first. We do recommend just using embedded; the database tends to be relatively small (few hundred mbs usually, even with lots of packages). Thanks, Steve

Hi @brandon_owensby_2976, Off the top of my head, I don't know how handle locale for this particular circumstance (either DotNet::Test or the Image-based services as a whole). But in general, I believe it's a distro-specific (maybe) environment variable (LC_ALL I think?). It may vary case-by-case. We do have an open roadmap item for reviewing Image-based Services and DotNet::Test operation as a whole (it's linked to the other comments you made), so I'll add this request to that. Cheers, Steve

And just as an FYI (not a complaint at all), for that specific post... we'd really only need the stack trace. The technical details.... they were.... well, as you said, you used AI Haha @stevedennis I understand, no offence taken Thanks for the configuration as code post there seems to be some workarounds to actually being able to configure some things through code though I think apxltd has litte bit too pessimistic take on configuration as code It sounds like he has had to taste only the bad side of it. If properly set up with working processes I only think its good. The most important thing being review and versioning of the deployment of the infrastructure with Proget setup included imo But we can continue the discussion in the configuration as code thread instead

Hi @amy.j , Good news! Thanks to another user, we were able to figure out how to get a Publish Date for Maven artifacts. It seems to work on MavenCentral, and possibly other servers -- it realy depends on if they implement Last-Modified headers on HTTP requests. This will be implemented in today's release via PG-3411 Thanks, STeve

Thanks for the quick addition of this feature. I was wondering about the connector filters for OpenVSX. What format do the filters expect? It looks like I need to prefix the extension name with a wildcard to whitelist a specific extension. Is that correct?

Hi @peter.shrosbree, Thank you for your detailed analysis of this issue. We were able to discover a version mismatch error in our NuGet V3 Package Metadata API. Once we retrieved vulnerabilities for a package name, we built the vulnerability array for each version by only checking for a version, not package name. So vulnerabilities that had multiple package names associated could show for multiple packages. This is only an issue with the NuGet API, as internal ProGet mechanisms check differently. Turns out this has been an issue for quite a while now, but it only became noticeable once we launched the NuGet Vulnerability API implementation in 2026.11. We will have this fixed, PG-3410, in tomorrows release of ProGet 2026.13. There is also an issue, PG-3401, that fixes an issue in the NuGet Vulnerability API when a single version is affected. As for the security.inedo.com page for PG-2129406, the version range is actually correct. The version range of ≥ 4.0.0 & < 4.5.1 is the same as [4.0.0,4.5.1) which means versions greater than or equal to 4.0.0 and less than 4.5.1. That is why the package in the ProGet UI did not display a vulnerability for 8.0.0 - 9.0.21. Please let us know if you need better clarification on any of this. Thanks, Rich