ProGet: Auto package promotion from NuGet mirror?

scampbell_8969

We currently have a NuGet mirror feed which points to nuget.org. We don't use packages from it directly in our CI/CD builds. Instead, we have an "approved" internal feed that we use for that. We populate that feed by promoting from our NuGet mirror feed.

Is it possible to configure our "approved" internal feed to have new versions of approved packages automatically detected and promoted from our NuGet mirror feed?

atripp

Hi @scampbell_8969,

ProGet does not have this feature; we've thought about it after some customer discussions in years past, but I don't think anyone's asked about it until now. And it wasn't the right solution for those customers.

We concluded it would be kind of complicated to document / configure / troubleshoot, especially once we got into the details and specifics. Here's some of those:

A new version could be unwanted, especially after the "Moq Meltdown" from last year
Patch versions are probably okay, but new major versions should still be vetted
Licenses can (and do) change between versions
New versions It's also a vector for malicious update attacks
Some kind of filter would be needed to select package for auto-promotion
Very few packages get frequent updates, so this doesn't seem like it's solving a big problem

Instead we created a "latest version" compliance flag that allows you to flag packages that aren't the latest patch version. We'll see if that's popular.

Thanks,
Alana

dan.brown_0128

To piggyback on this -- this has been an idea we've been interested in as well. As part of our corporate policies, generally once a package has been approved (at a name level), all subsequent versions are OK assuming there's no vulnerabilities or license issues. Denying a request for this is very rare.

By automating version promotion, it would allow developers access to newer versions of packages sooner, making access easier and devs will be more likely to upgrade.

We thought about doing this by filters, but managing that list would quickly get out of hand.

This isn't a critical functionality for us today, more of a nice to have.

scampbell_8969

@dan-brown_0128

Our policies are very similar to what you described. That's why I asked if this was possible.

atripp

@dan-brown_0128 @scampbell_8969 thanks for the feedback!

I've added a note to our internal board for ProGet 2025 roadmap consideration; after we get through the PostgreSQL migratoin, we will likely focus on SCA feature improvement, but maybe there will be room for this.

Any guidance/ideas on the UI/docs would be really helpful when we come to revisit it.

https://inedo.com/products/roadmap

apxltd

Hi @dan-brown_0128, @scampbell_8969,

We were reviewing this as part of our ProGet 2025+ roadmap, but I'm not sure if it makes sense to do. To summarize...

"Once a package has been approved (at a name level), all subsequent versions are OK assuming there's no vulnerabilities or license issues. However, the current promotion model requires that we promote each and every version. By automating version promotion, it would allow developers access to newer versions of packages sooner, making access easier and devs will be more likely to upgrade."

What about just using a connector with package filters in this case? For example:

Create feed nuget-unapproved, nuget-approved
Restrict promotion from nuget-unapproved -> nuget-approved
Create connector NuGet.org-all and associate with nuget-unapproved
Create connector NuGet.org-approved and associate with nuget-approved
Edit connector filters on NuGet.org-approved to block everything except packages you want

This would be possible today and would avoid adding a complex feature

Thanks,
Alex

dan.brown_0128

In theory, having a filtered feed and promoting from that would work -- at least it would accomplish the same result.

The initial creation of the filters, at least in our case, would be quite lengthy (we have ~2500 packages in our approved feed today). Also, how scalable is the feed filtering? I could see the risk of performance issues as the number of packages in the filter grows.

I need to double check our policy/procedure for one specific. If package X is approved at version Y, I am not certain that versions prior to version Y are inherited in the approval. I know future ones are, and I think prior ones would be, but need to verify.

apxltd

@dan-brown_0128 thanks for clarifying

2500 is a lot more than I'm thinking... I was envisioning a handful of frequently-updated / highly-trusted packages (like AWSSDK, ). I think the UI would struggle a bit.

Thinking about this further... a blanket "all future versions are OK" policy seems like it will cause more problems than benefits. That's a lot of decision-making burden to shift to developers, and they're just going to hit "update" the moment they're prompted.

Best case scenario, that update delivers Zero Business Value... but there's a chance it'll introduce a regression, etc. I'd really need to study the data before recommending a practice like this (let adding a supported usecase for it) I'd be open to some sort of "automatic approval" feature, but I'd want to see some other factors in there, other than just "name matches X".

As it stands, "package approval/promotion" isn't very widely used as it's solving a problem most organizations don't believe they have. Instead they drop $300K+ for Clownstrike or another security tool and believe it just "does everything for them". At that price, how could it not!

So I think it's best to pin this for a bit. It's still a pretty "frontier" discussion/feature, and I don't want to "invent" something that's not going to get a lot of widespread use.