ProGet - Yanked package behaviour

Ashley

Hi,

Could you please explain the behaviour around how ProGet handles yanked packages for public feeds?

Scenarios:

The package is yet to be downloaded to ProGet, and the user attempts to download a janked version. I'm sure ProGet will block the download in this case.
The package has been downloaded to ProGet, and is then yanked from the remote. Will ProGet update it's feed index to mark it is yanked and also remove any local files that have been previous downloaded?

This is mainly aimed at PyPi - but I guess the same behaviour would apply to other feed types.

Thanks!
-Ashley

dean-houston

HI @ashley,

A package's unlisted state (i.e. "yanked" in PyPi or Ruby) is server-side metadata, similar to download count. That means, once a package moves servers (i.e. from pypi.com to ProGet), that metadata is owned and maintained by the new server. When a package is cached/pulled into ProGet, that state is copied from the remote server.

An unlisted/yanked package may still be downloaded and consumed, and it's up to the client to determine how to use (or not use) packages with that status. ProGet simply displays an "hidden icon" next to unlisted packages. Visual Studio does not display them at all. I would imagine pip doesn't consider them in dependency resolution and might give a warning if consumed directly.

That said, the OSS Metadata Updating & Caching will routinely sync Listed and Deprecated statuses, but it comes at an obvious performance cost. Or you can use retention policies to more aggressively delete cached packages.

Hope that helps.

--Dean

Ashley

Thanks @dean-houston

That all makes sense. If a Vulnerability is identified in a package that has been downloaded, will ProGet remove that from storage?

We are trying to identify what containment actions we need to take in case we identify a high vulnerability package that needs to be removed from our network entirely.

dean-houston

Hi @Ashley,

It wouldn't make sense to try removing "vulnerable packages" from storage -- in fact, even download blocking doesn't make sense in most cases, as it tends to lower the organization's security posture and leads to other problems.

Even the package with the "world's most severe vulnerability" (i.e. the infamous log4shell) is harmless unless it's incorporated in an application in a certain way and the application is exposed in a certain manner that would allow a malicious actor to exploit it. Trying to block access or remove these harmless library files from the network will substantially lower the organization's security posture, for a number of reasons.

I'd encourage you to check out our best practices guide: Vulnerability Management Done Right with ProGet. In particular:

Preparing for a Category 5 Vulnerability to learn how to handle the "next" severe vulnerability
Blocking & Containing Vulnerable Packages for general best practices in addressing them in pipelines

I think the Preparing for a Category 5 article will help you create that template process for what to do when that high vulnerability package is is identified.

Hope that helps

-- Dean