Hi @xabur ,

Thanks for sharing the additional information! I've been meaning to research this more in depth, but just ran out of time.

I can't quite seem to figure out what Open VSX is exactly. So far as I can tell, it's like an alternative the Visual Studio Gallery. Meaning, you plug in https://open-vsx.org/ in VS Code, and then all the requests go through their service instead of the official gallery?

If that's the case, what's the use case? They appear to have all the same extensions, so this just feels like one of those "GooglePlay store alternatives" on Android... except there's no account/registration/etc required with the Visual Studio Gallery. Right?

Open VSX clearly seems to be popular, I just don't understand why.

In any case, if a well-supported project "reverse engineered" the official gallery and then made an alternative, that kinda paves the path for us. We don't want to be the first or only game in town, when it comes to supporting feed types.

Thanks,
Alex

Hi @fabrice-mejean ,

Thanks so much for the detailed information and offer to connect further! Very interested in that and I will definitely take you up on that :)

Please give me a little time for that; I've got some travel coming up and then a bunch of other things... so I'd like to connect when I can really focus on some of these future things.
.
Cheers,
Alex

Hey @fabrice-mejean ,

Thanks for the thoughtful feature request!

My somewhat rhetorical question is.... don't you have another tool that manages pipeline lifecycle? Doesn't that tool just handle promotion and then "call into" ProGet.... and thus, ultimately, does it really matter if ProGet's information is wrong?

But here's the long explanation / rambling...

--

So we actually implemented a whole new feature for ProGet 2026 called "build pipelines", but then I scrapped it because it just didn't "feel right".

The major highlights were this:

• add concept of "Pipelines", which are a collection of stages; the current stages would be converted into the Default pipeline
• add "enforce stage sequence" on a Pipeline, which would allow you to just promote without selecting a stage and error if you tried otherwise
• add concept of "Releases", which group related builds together under a common release number and Pipeline (basically the BuildMaster definition)

This would allow you to do a workflow something like this:

pgutil builds releases create --number=1.0.0 --pipeline=major
pgutil builds scan --build=1 --release=1.0.0
pgutil builds promote --build=1 --release=1.0.0 # build -> test
pgutil builds promote --build=1 --release=1.0.0 # test -> qa
pgutil builds promote --build=1 --release=1.0.0 # qa -> prod

Since the build was promoted to the last stage, the release status would become "deployed" or something like that. By default, this would "archive" the previously deployed release, which would hide all those related builds from the dashboard.

This model made sense to me, as a single project/application often has multiple releaes and multiple deployment pipelines, and this kind of modeled that.

That said, the big issue I have is that "Releases" seem to be a foreign concept to many organizations; they simply produce a stream of "builds" and then someone "picks one" to deploy. So, it just feels like we're introducing a concept they don't use.

And then I thought... what exactly would we be solving here? Is anyone actually looking at "stages" or "pipelines" in ProGet? Don't they have some other tool for this? Why are we even modeling these things visually?

The more I thought about it, I kept circling back to "main value" of stages is "issue creation" and "retention" --- not "visualization". So I thought, maybe we should just pgutil builds audit generate issues? Does anyone use issues anyways? .

And then I kinda gave up after that

Anyway, I'd still like to "do something" here, but I'm not sure I'm "connecting the dots" just yet.

There are a few recurring themes users talk about:

• Docker container images and the relation to sCA/covernance
• Package-based applications (e.g. NuGet for OCtopus deploy, Universal Packages)
• Library packages

I can't help but wonder if we can adapt the SCA Builds/Projects to encompass these ideas a little better. Libraries obviously can't have a SBOM (they have dependency ranges instead), but there's gotta be "something" we can do here.

I do feel I'm rambling here, but if we're going to do something, it should be an opiniated approach that introduces a new/better way to solve problems without a lot of friction.

Personally I think visualization is huge, but what's the visuzliation problem we can solve with our tools

Thanks,
Alex

@jens-viebig_4541 ooh good catch!

That guidance is outdated as of ProGet 2026, where we no longer recommend/default to blocking Noncompliant packages.

We should rewrite/republish the article to be more focused on guidance, update the screenshots, etc. I'll add that to the list.

Hi @jens-viebig_4541 ,

In very early versions of ProGet, we would filter specific versions from connectors (i.e. remote feeds/repositories) but it caused all sorts of problems due to client (i.e. npm, nuget, etc.) behavior and server API (npmjs.com, nuget.org) limitations. But the biggest problem was Developer Experience, and the fact that the behavior was simply befuddling.

When "random" versions suddenly go missing from the API, users will see a totally different dependency resolution result. Sometimes it would yield build failures.

Troubleshooting this is an pain in the ass, especially for those nested dependencies, since the client provides no useful information. They can see the versions of "their packages" are both in npmjs.com and ProGet. The end result is end users saying, dependency resolution with ProGet is broken, so we just use npmjs.com instead.

Long story short, I don't image we will return to filtering specific versions. It just causes more problems for everyone for no real benefit.

Addressing Malicious Packages

As for addressing malicious packages, this is simply a risk you have to accept. The question is how much Developer Experience you want to sacrifice to minimize the risk.

First, you really can't rely on malicious packages ever being discovered . I mean, just look at the XZ Utils (CVE-2024-3094) backdoor; that kind of code could be in any library you're using now. So, the first step has nothing to do with Malicious Packages... but it's to make sure all of your apps are deployed under a Minimally Viable Security Posture (MSVP) and track which dependencies go where using ProGet's SCA capabilities.

That said, if you do absolutely nothing, chances are you will be totally fine. As we wrote in Changes to Malicious Package Handling in 2025.20 and Beyond: the overwhelming majority of malicious packages are basically bot-created spam that no one will ever see, let alone use. These packages don’t rely on typos, but instead random, “package-sounding” names generated by some LLM.

In addition, Microsoft/GitHub seems to be undoing the braindead npm design descision to run arbitrary scripts at install time. I'm shocked that terrible idea survived this long. So, that will significantly reduce the attack vector, as developer machines can no longer be compromised by simply installing a package.

Noncompliance for Recently Published Packages

That said, the risk of harm caused by newly-published malicious packages pale in comparison to the real harm caused by regressions from constant upgrades. There's about a 0% chance of being harmed by a malicious package, but nearly a 100% chance of having problems when your developers always upgrade.

So, it's a good idea to say newly published packages (like 30 days, not 1 day) are noncompliant. You'll just need to figure out how to balance Developer Experience with that. We have a lot of options, from using Package Approval Workflows (pretty heavy handed) to allowing exceptions for single packages.

We do not recommend blocking noncompliant packages, especially for npm. Instead, use pgutil builds scan as discussed here: https://guides.inedo.com/vulnerability-management/containment/

I understand that pnpm has some kind of rule you can configure to not resolve "newer" dependencies. So you could just set that to like 31 days, and set ProGet's to like 29 days. Or 15 days, 14 days.

But a single day isn't going to do anything for you, except provide a false sense of security while maintaining the real risk of regressions from a "always upgrade" culture.

--

Finally... as for what Sonatype does, I'm skeptical. Based on the many customers that migrated from Nexus to ProGet, there's a rather large gap in advertised features and functionality, especially when it comes to stuff like this. Just taking a quick look, that feature looks defunct anyway and likely doesn't get much/any use.

Regardless, filtering versions from feeds causes problems than it solves, so it really doesn't make sense to do.

Hope that helps,

Alex

Hi @imm0rtalsupp0rt ,

We've published a version of the article now:
https://docs.inedo.com/docs/proget/feeds/chocolatey/howto-chocolatey-proxyccr

Let us know your thoughts or freel free to submit a PR should have have any suggestions!

Thanks,

Alex

Hi @Nils-Nilsson ,

Thanks for the feedback; we discussed this with the team some more.

The use case makes a lot of sense, especially with risk profiles introduced in ProGet 2026. Instead of exposing Policies (which have a bunch of package-driven rules) and blocking, our thoughts are:

[1] Allow risk profile to be set/configured on Docker feeds; behind the scenes this would create Policy, but none of the rules would be used

[2] Allow scoped assessments on Docker feeds; this would also use the feed's policy

[3] Add pgutil containers audit command, which would display vulnerabilities and error if any are severe

The issue we have with "blocking" downloads directly is that the Docker/Kube/Podman/etc. do not expose HTTP error messages and this becomes very painful to debug/troubleshoot.

However, running pgutil containers audit can "break" any automation process (nonzero exit code) and will list all vulenrabilities etc.

LEt us know your thoughts!

Thanks,
Alex

Hi @Nils-Nilsson ,

We're considering "doing something" about this for our ProGet 2027 roadmap, but I really want to think about how this should be handled in ProGet. I want to create something that actually is helpful in identifying real security risks... and I'm not sure if our package-intended Policies is the move for Docker containers.

One major issue is that nearly all vulnerable packages in a container IMAGE pose zero risk. Even if the component were used (most aren't... they're just installed), exploitation would require someone SSH'ing into the container and running interactive commands. PGV-2387734 is a great example of this.

It's actually more risky to remediate the vulnerability and become "sensitized" to vulnerabilities like this. So, we want to make sure we can find way to "permanently mute" these for certain containers - and perhaps that involves saying "I do not actively use this component that happens to be installed in the image"? I'm not sure.

There are also some issues with the ways vulnerabilities work with certain Linux distros; for example, the "patch version" varies by operating system, and that information isn't readily available in the vulnerability database and ProGet isn't analyzing which operating system the platform is using.

We have a rough idea of treating Docker images to be more like SCA Builds than Feed Packages, in that an entire container image would be considered complaint. However, how many container images are built (it's done at CI for a lot of people), how few people seem to use pre-release tagging, etc., I don't know what makes sense here.

Anyway let me know your thoughts!

Thanks,
Alex

Hi @pg_user_8607 ,

Thanks! If you haven't already, please do check out our Migrating from Sonatype to ProGet guide.

[1] This is a common configuration, and it looks like anonymous is allowed based on the screenshot. It's hard to say withtout more troubleshooting. I would try using the Test Privileges function , which allows you to select a user, feed, and then it will show you all the task attributes available.

[2] To be honest, our users have not found those analyses to add any real value (outside of describing what the library does). So, starting in Q1 we've shifted our research efforts to align with the big changes to vulnerability management in ProGet 2026, including Category 5 Vulnerability Research. Check out the Vulnerability Management Done Right with ProGet guide to learn more about what's coming!

[3] No plans... in retrospect, there's no value in monitoring activity outside of checking the /health endpoint periodically. In fact, we've seen the opposite -- even monitoring HTTP traffic for abnormalities creates false positives that just wastes everyone's time.

For example, if NuGet.org is having an outage, then your NuGet feeds connect to nuget.org will run slow, as the connector times out.

[4] I suppose so! We'll update once we get ProGet 2026 out :)

Cheers,

Alex

@geraldizo_0690 thanks for clarifying!!

That's an interesting use case (i.e. using Otter/ProGet for vulnerability monitoring), though one we haven't really thought about. I can definitely see how the tools could work together to support that, but I suspect there are some key features/functionality that are missing (like getting notified, etc). Plus, a whole bunch of documentation and marketing to support the use case :)

It feels like we're taking on a whole new niche here, and there's a lot of solutions/players in this space. A quick search revealed Wazuh, OpenSCAP, Grype, Syft, etc. I've never heard of any of those, so it's hard to know how we could do something better. That would be first step -- why build "yet another solution" to this problem?

From a technical/solution standpoint, I think that something like a "pgutil but for system packages" might be a better choice. Just run that after a system update on the hosts, and that would push information to ProGet.

That simplifies configuration/management, and the two systems already have network access -- whereas opening up the host via SSH requires higher-level permissions, etc. It's lot of "adoption overhead", which means users won't really try it out.

A:nyway... it seems like we just need to "start from scratch" on this one. Definitely interested to learn more, but for now the main question would be "what problems can we uniquely solve that the existing tools can't".

Best,
Alex

Hi @no-doubt,

We are software engineers that provide technical support to technical end users. We cannot help non-technical users who provide no technical information. Moreover, I'm not willing to work with users who call our products "a real pain" and share counter-productive "facts" about how easy competitive products are. You should know better.

I'm going to lock this thread, but I'll give you another chance though.

If you'd like to continue your evaluation and receive technical support, please spend a few moments reviewing other forum posts to see how users communicate with us. If you feel comfortable doing that, then post again. If not, then it sounds like you've got two products to choose from.

Sincerly,

Alex

Hi @geraldizo_0690 ,

Thanks! That's pretty much where we left it, an "interesting feature" with no real demand. I'm glad you "get it" though and see some value here :)

This allows users to check whether the packages they use have already been updated with the latest security updates.

So to clarify, your envisioned usecase is system/Debian packages? What would you do on the Otter side? Orchestrate updates of those packages?

Cheers,
Alex

PS -- other issue is the list to address, easy fix just haven't gotten to it yet w/ PG2026 stuff

Hi @george-bowen_9415 ,

This was brought up at a internal review meeting, but I didn't want to have this added because I don't want to start adding configuration options to the AD v5 Directory - the goal is to "just work" for 95% of the use cases, and your configuration (37K users, 101 direct groups, 217 indirect groups) definitely falls within the 5%

So, our plan is to update the documentation on how to configure LDAP / OpenLDAP directory with AD. That's technically more work than adding a checkbox.... but this aligns with how most other products integrate with LADP/AD.

We plan to document this in the coming weeks, but in the meantime you could probably figure it out without the tutorial.

Cheers,
Alex

Hi @geraldizo_0690 ,

Thanks for trying out the feature! Unfortunately I think this feature broke around ProGet 2023 and no one seemed to notice it; we were actually planning on removing it in ProGet 2026.

We build the feature ages ago, but no one ever asked for it. It just "felt" like a "nice idea" at the time, but we never really thought out a proper use case. So was never documented very well and it would seem no one used it

Anyway... I'd be open to reviving it if we could actually figure out a use case. What are you trying to do? Would love to get an idea to see if we can solve a real-world problem here

Thanks,
Alex

Hi @paul-moors_5682 ,

We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow.

One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice.

Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical.

Cheers,
Alex

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex

Hi @davidroberts63 and @mikael ,

Thanks for the insight and ideas!

I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run?

Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me.

Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;)

I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on.

Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file.

Cheers,
Alex

Hi @mikael ,

We have no plans for this and honestly, I don't think I'd recommend setting up a tool like ProGet in this manner.

Outside of some very specialized use cases (like setting up labs for testing, or nodes in a ProGet Enterprise Edge Computing Edition) I don't really see the benefits. Only headaches.

It might sound fine on paper, but every company that has set it up this way has regretted it. And you will to. The reasons they want "fully reproducible configuration" is usually:

• so we can store configuration in versioned code
• so we can easily replicate it in a testing environment
• so we can easily migrate/move to a new server

Those seem nice, but it totally fails in practice in my experience.

First, you can't "rollback" most configuration. Say you fat-finger a configuration file and delete half your feeds. There go all your packages. And when you realize you've got gigabytes/terabytes of content to deal with, plus all the metadata in storage, this is a huge headache.

The configuration you can make idempotent (say, permissions/users) is so much more a pain to work with than a UI. Again, more error prone you lose all the benefits of visual cues, input verification, etc. You fat-finger the wrong setting, and you get some obscure error instead of a helpful red box next to the text box.

The regret comes in realizing they've created a buggier environment that isn't properly tested, and is somehow less "portable" than an ordinary installation. A year later, when the new team comes in, they usually have to figure out how to "undo" it -- and you can probably guess why we need to get involved to untangle the mess.

Cheers,
Alex

Thanks for the additional feedback @ben_0435

Mostly for my notes, in the five months since @Jonathan-Engstrom shared Microsoft's initial efforts at supporting a WinGet private repository (i,e. winget-cli-restsource), it looks like they've already abandoned their efforts.

• Last code commit June 26, 2025
• Last closed issue July 4, 2025

So at this point, my assessment remans the same: WinGet is basically just the Windows Store, except you it run from the Commandline and has a ton of shady, unvetted packages from internet randos

I feel someone should totally Polymarket whether Microsoft will finish WinGet --or-- just create yet another package manager that's somehow more BingAI friendly.

I'm looking for a solution to titrate that scary giant community repo so it can be managed better... I want upstream.. but only select things. I want to publish apps as necessary for the public/private feed.

I believe that solution is called "Chocolatey"