Unlisted NuGet versions still returned by ProGet V3 flatcontainer index — restore tries to download unavailable version

daniel.mccoy_4395

Hi all — looking for advice/workarounds.

We’re using ProGet as our NuGet V3 feed. If we unlist a package version in ProGet UI, it disappears from Visual Studio Manage NuGet Packages browsing (expected), but restore still treats it as available.

The version is still returned from:
/v3/flatcontainer/<package-id>/index.json

In our case:
• OpenTelemetry.Api 1.13.1 is unlisted/deprecated
• restore still attempts: /v3/flatcontainer/opentelemetry.api/1.13.1/opentelemetry.api.1.13.1.nupkg
• download returns HTTP 400
• restore/build fails

So metadata appears inconsistent: version is advertised in flatcontainer index but package blob is not retrievable.

Questions:

Is this expected behavior for ProGet “unlist”, or a feed inconsistency?
Is there a ProGet setting to exclude unlisted versions from restore metadata?
Is there a recommended reindex/cleanup task to remove stale versions from flatcontainer index?

Thanks for any guidance.

stevedennis

Hi @daniel.mccoy_4395 ,

This is how unlisted packages are designed to work; it's just a flag in the metadata, and clients will treat it however they'd like. Visual Studio hides them but lets you download them, ProGet shows them with a little "unlisted" icon.

As for the download error, the 400 sounds like you've configured "download blocking" perhaps? Check the feed's policy settings.

We generally don't recommend configuring download blocking, but using pgutil builds scan instead; see https://guides.inedo.com/vulnerability-management/containment/

Hope that helps,

Steve

daniel.mccoy_4395

Hi @stevedennis ,

Thanks for the clarification.

Yes, we do have download blocking configured, and we're also performing build scanning in our CI/CD pipelines.

We're a little hesitant to disable download blocking because our concern is developer experience. If the first time a developer discovers they've introduced a noncompliant package is when they raise a pull request (or when the build pipeline runs), that can result in wasted effort and rework late in the development cycle.

What would Inedo recommend as the preferred approach for identifying noncompliant packages earlier in the process?

I had a look at pgutil builds scan, but unless I'm misunderstanding how it works, it appears to upload the SBOM to ProGet for analysis. We don't currently provision every developer with a ProGet account, so I'm struggling to see how we'd integrate that into a local developer workflow.

Is there a recommended way for developers to get feedback on package compliance before committing code, without relying on download blocking in the feed?

Thanks,
Dan

atripp

Hi @daniel.mccoy_4395 ,

Actually, developer experience is a big reason we don't recommend using Download Blocking. A 400 error provides no real context. Developers can see something is wrong, but not how serious it is or what to do next.

First and foremost, an unlisted package should not be noncompliant. An author may decide to unlist their package for any number of reasons, including simply not wanting too many versions to show up in a list.

This would mean that, all of a sudden, a build deployed to production can suddenly be considered as noncompliant just because an open source author arbitrarily flipped a switch on NuGet.org. That's not to say you should ignore the unlisted flag, but you should definitely not put it at the same categorization as a GPL3 license or severe vulnerability.

"Compliant with Warning" could be a more appropriate status here, but keep in mind that developers swill naturally upgrade dependencies as they do platform updates, so it may not even be worth worrying about. Especially if it leads to constant warnings -- in that case, warnings become meaningless.

Noncompliant packages should be rare for the same reason. If noncompliant can be determined by an OSS author's whims, then it really caries no meaning and no one (especially your developers) will understand/appreciate what it means.

As for the workflow to use, we recommend running pgutil builds scan when that pull request is run. That will not only put the build in ProGet, but it will produce a text report with warnings or noncompliant packages. A ProGet login is not required.

If there are Noncomplaint packages or warnings, the developer can then comment on the PR why it's nothing to worry about. If it's always the same package/issue ("we cannot upgrade from this 5-year old library and replacing it would be a substantial effort"), then you can formalize that as an exemption.

The advantage to this workflow is that, if a deployed build later becomes noncomplaint (typically due to a vulnerability), then you can decide how and when to address it. The wrong time to address noncomplaint packages is "the next time a developer happens to open this project".

Overall, what you want to avoid is having developers load a project for what should be a trivial change and then have to upgrade dependencies because it produces pointless warnings/errors. That will just create a "constant upgrade" mentality. That leads to constant regressions and constant headaches for testers or end-users, who have to deal with strange and unexpected errors from library upgrades.

Hope that helps,

Alana