Hi @atripp, I've encountered the issue again, and have been able to track down the issue. Seems related to S3. Pulling the image: failed to pull and unpack image "<proget>/ghcrio-proxy/fluxcd/image-reflector-controller:v1.2.5": short read: expected 37867329 bytes but got 32624449: unexpected EOF ProGet did not log any errors, and then serves the blob happily with a 200; Request finished HTTP/1.1 GET http://<proget>/v2/ghcrio-proxy/fluxcd/image-reflector-controller/blobs/sha256:266ebec216df42de9ed7c4d07422168f3329eecf923306036386404f10c5a0f8 - 200 32624449 application/vnd.oci.image.layer.v1.tar+gzip 223.6409ms So ProGet is serving 32624449 bytes, which is what the client rejects. expected: 37867329 = 7 x 5242880 + 1167169 (7 full parts + final part) stored: 32624449 = 6 x 5242880 + 1167169 (6 full parts + final part) missing: 5242880 = exactly one full 5 MiB part It seems ProGet failed to store one part of a multipart upload to S3? In case it can help speed things up, the usual AI assistants came up with these findings: S3WriteStream.cs in inedox-aws (master, last changed in 97a95a44). Parts upload in the background as a task chain built in CheckAndBeginBackgroundUpload (L192-L195). Each part is attached with ContinueWith(_ => ...), which runs whether or not the previous task faulted, and the previous task is never checked. If UploadPartAsync for part N throws (for example after the SDK's retries run out), the exception is lost. Part N+1 still uploads, and uploadTask then reflects only the last link in the chain. CompleteUploadAsync awaits that task (L93-L94), uploads the final part and calls CompleteMultipartUploadAsync with a part list that lacks part N (L115-L140). S3 accepts non-contiguous part numbers, so the upload succeeds with an object exactly one part short and no error is raised. ProGet then stores and serves the blob under its digest. Write(byte[], int, int) and WriteAsync(byte[], int, int, CancellationToken) ignore offset and always read from index 0 (L41, L46). Any caller that writes from a non-zero offset stores the wrong bytes at the correct length. Edit: confirmed this is the (missing part) issue: I pulled from my ProGet instance and directly from the upstream, and compared the blobs. The ProGet blob is missing "part 2" of the blob exactly.

Hi Steve, i would put a hint in two places on this page: "3. Use a Free, Automated Issuing Service, such as Let's Encrypt with a tool like win-acme to get short-term certificates" All such Let's Encrypt certificates are issued by intermediate CAs. PFX files generated by ACME clients and directly loaded into ProGet would therefore cause the issue initially described. This is probably also the easiest approach to reproduce the issue. "2. To use a ".pfx" file that was exported from your certificate store" Based on my observations this would still require potentially involved intermediate CA certificates to be present in Windows' certificate store, that ProGet sends those to clients allowing them to validate the full chain. Thank you for addressing the problem this way.

@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

Hi @wechselberg.nisboerge_3629 , Thanks for letting us know; we'll get this fixed via PG-3408. We're targeting ProGet 2026.14 (October 30). Cheers, steve

@rhessinger It's ok, we can wait a couple of days :) have not rolled out the switch over from ADO to Proget fully yet. Thanks anyway! :)

@stevedennis and @inedo-engineer I appreciate that. I really didn't care about reputation except that it was preventing me from replying back to my tickets and saying thank you. It said my reputation wasn't high enough to have that many posts and I had to wait a while before I could say "Thank you" on another post. Maybe when you turned that feature off you fixed that issue too. I just thought I'd let you know more details so if you upgrade again you can keep track of that. Thank you, Brandon

Hi @bobmaurer , Thanks for the inquiry! Hope you don't mind a little push back on this -- but we'd encourage your security team to read our Vulnerability Management Done Right with ProGet. While we understand where they're coming from, the "weekly download" report is an anti-pattern these days and will lower the organization's security posture... which probably goes against their mission The main reason is that it improperly treats vulnerabilities as security incidents while providing no realistic path to mitigate them. This is backed by a huge body of research, including our own State of Software Supply Chain Security and reports from industry analysts. For example, they see "Joe Developer downloaded JsonLib 3.4.1, which has PGV-12345" -- what exactly are they going to do with that information? Contact Joe and ask him how he used it? Do they expect Joe to trace through 1000's of transitive dependencies across dozens of projects to see if he even knows where it's used? Tell him to uninstall it? Try to figure out if he caused damage? Or what application it was added to? Obviously not, because there will be so many packages with vulnerabilities that no one knows where they came from. The "best case" is to get aggregate data -- and ProGet already provides that, but by application/deployment state (which is what really matters). Anyway -- the best way to handle this is by implementing Software Composition Analysis in ProGet - we have all the tools to help Prepare for a Category 5 Vulnerability Thanks, Steve