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
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
Hi @carl.westman_8110 ,
I think we'd recommend a work-around of just asking us for help :)
Based on other customers who've tried to use AI to help with ProGet issues, I think you'll be spending too much time spinning your wheels. The AI guidance is almost always wrong, because the pattern-matching stack traces that were scraped from Stack Overflow are to fix coding errors. That, and we fix errors really fast, so even if it scraped an answer, it probably was an old version.
Sometimes it makes matters worse; we saw AI guide one user to do all these strange database changes (connection string, adding indexes, etc) -- when the underlying issue was totally unrelated.
The information in the Diagnostic Center serves two purposes:
It is not to proactively check for health, etc. It's only to troubleshoot known issues. And if the issue is not obvious to you, then we can help answer. Our goal is to make this as obvious as possible.
Thanks,
Steve
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
This is a generic forums system that we're using for public-facing support of a niche software product, so most of the features like voting/reputation don't really apply.
Honestly I didn't even know those were features.... we recently upgraded the software, so maybe these were added? Anyway I just disabled them since we don't use them :)
We have internal tracking for everything - either as a scheduled YouTrack ticket (which we link to) or a roadmap item (internal project tracking) that we periodically review and schedule as tickets.
Thanks,
Steve
Hi @clsa,
If you're talking about the certificate errors under Admin > HTTPS, I wouldn't worry about those. An application does not need to validate its own certificate; it's only used to encrypt/decrypt the traffic.
The server transmits a copy of the certificate (without the private key), and the client validates the certificate before transmitting data.
Without getting into too many technical details, the only thing that really matters is if clients can connect to the application (ProGet) using HTTPS or not. There are a lot of reasons that may prevent the application from self-validation and it's not really worth trying to fix, since it's only used on that page to help catch basic errors.
Thanks,
Steve
Hi @Valentijn,
It looks like when we migrated pgscan in to pgutil, the functionality for this was removed. We will add a new flag to pgutil builds scan called --do-not-scan-npm that will ignore scanning for npm packages. I should have this released later this week or early next week. I will let you know as soon as we push the change.
Thanks,
Rich
Always happy to help! I have actually already made the fix internally. If you would like, I can provide a pre-release build of ProGet 2026.13 that includes the fix.
Thanks,
Rich
Hi @clsa ,
We're not aware of any bugs or issues; SSL and Certificate handling is all done at the Operating System (Windows) or Platform (.NET) level; we just point the system to the file. In my experience there's usually some obscure registry setting that will control stuff like this.
Thanks,
Steve
You may be right here; we'll just need to dig in and research a bit more. "Everyone" tests with and assumes a Linux Stack when working with Docker containers/agents, so it's likely this is just an edge case that we need to review further.
We'll add this to our roadmap to do down the line.
Thanks,
Steve
@brandon_owensby_2976 thanks!! This one was also added to our roadmap to review.