ProGet - SCA Missing Package because of NuGet proxy cache miss

jw

I configured a NuGet caching proxy for nuget.org.

When uploading a sbom.json I noticed that a number of open source NuGet packages are reported as "Missing Package". One such example is Microsoft.Extensions.Localization.

These packages do exists on nuget.org and ProGet is also showing them correctly. The issue is that these packages are never actually downloaded during the dotnet/nuget restore process (in fact, they are never part of the build machine's local NuGet package cache) because the dlls of these packages are shipped together with the DotNet SDK.

ProGet SCA is reporting these packages are missing, because since they were never restored, they are not part of ProGet's proxy package cache.

It is possible to click on each missing package, get redirected on the package page and then hit the download button to populate the proxy cache and this also resolves the missing package issue, but this is very inconvenient.

I think there should be a way to automatically populate the proxy caches when uploading SBOMs.

Am I missing something here?

atripp

Hi @jw ,

Thanks for the feedback; we definitely have plans to review/improve our SCA/SBOM processes, so my answers will be questions ---- please don't hesitate to give us additional feedback in the aggregate when you have a chance :)

As for this particular case, we've seen this too - and just found that downloading the package caused the issue to go away, and that was simple enough since there weren't too many packages (just lots of annoying clicking).

I don't think we want to have ProGet automatically download/populate the feed with packages, but perhaps a better way to handle this is some kind of rule or ignore setting for missing packages??

And it'd be nice if ProGet automatically shipped with a list of these too. I really can't think of any reason why anyone would ever want a notice of "Microsoft.Extensions.Localization" being missing. Can you?

This is probaly something unqiue to NuGet as opposed to other package managers.

Thanks,
Alana

jw

Hello @atripp,

this is a tricky subject indeed.

As for this particular case, we've seen this too - and just found that downloading the package caused the issue to go away, and that was simple enough since there weren't too many packages (just lots of annoying clicking).

While it can easily be resolved by downloading the packages manually, this is just not sustainable in the long run. Packages change, frameworks change and with every change there is the risk of yet another package missing in the cache and someone having to click again.

I don't think we want to have ProGet automatically download/populate the feed with packages, but perhaps a better way to handle this is some kind of rule or ignore setting for missing packages??

And it'd be nice if ProGet automatically shipped with a list of these too. I really can't think of any reason why anyone would ever want a notice of "Microsoft.Extensions.Localization" being missing. Can you?

Ignoring these packages does not seem like a good solution. Just because they are shipped with the .NET Runtime/SDK does not mean they are not susceptible for vulnerabilities, so I would rather have them being treated as regular packages with full vulnerability scanning etc.

This is probaly something unqiue to NuGet as opposed to other package managers.

Without knowing enough about the ProGet internals, this seems more like a proxy/caching issue for me. The question I would ask first is why ProGet does need the full package in its cache for the SCA tracking to work correctly.
Maybe some degree of metadata would be enough for that?

Maybe a parameter to SBOM uploading/analyzing could be introduced that enables downloading the required metadata or packages (depending on what is really needed) before analysis is started.

atripp

Hi @jw,

Thanks, good points! I'll try to explain the inner-workings a little more.

I would ask first is why ProGet does need the full package in its cache for the SCA tracking to work correctly.

This gets a little tricky and confusing; SCA checks for deprecation, vulnerabilities, and licenses.

Vulnerabilities only need the Package Id + Version, so no package is needed
License is generally stored in the package manifest file (e.g. nuspec file)
Deprecation is server-side metadata, which means ProGet's value may be different than the connector's value

So the design thought was, if only vulnerabilities were detected it would be weird. Hence, missing package issue only. Maybe this assumption is incorrect.

Maybe a parameter to SBOM uploading/analyzing could be introduced that enables downloading the required metadata or packages (depending on what is really needed) before analysis is started

This unfortunately gets pretty complicated...

ProGet will only store metadata for local/cached packages
Package caching is an optional setting (not all feeds use it)
There is no mechanism for automatically pull or cache packages

Designing a mechanism inside of ProGet to automatically download would not trivial at all for this use case. A PowerShell script to handle this on a one-off basis would probably be much easier.

FYI -- we are considering some kind of job that automatically download certain, trusted packages. This is in the context of "package approval workflows" and basically allowing something like AWSSDK (which frequently publishes new versions) to just always promote a new version. That's not exactly related to SCA/SBOM however.

Alana

jw

This paradigm "SCA in ProGet only works correctly when a package was previously put in the cache" should be revisited.

There already seems to be functionality in ProGet that can determine which feed provides a package, otherwise this link here /packages/from-purl?pUrl=pkg%3Anuget%2FMicrosoft.AspNetCore.Mvc%402.2.0 would not work. So the feed identification where to get the information from does not seem to be the issue.

Then on the subject of cache. Caches should be something that are fully transparent. If a package is not in the cache or caching is not available, then the required information should just be pulled from the source.

I do not see a difference between someone restoring a package from a feed and an SBOM requiring a package for running a complete SBOM analysis.

It would be really nice if this could be considered as an improvement to the NuGet SCA experience in ProGet. All the parts already seem to be there, they just need some wiring. Doing this externally with scripts or other hackery seems counterproductive to a well-rounded product.

atripp

Thanks for the additional feedback; this is definitely something we're revisiting for ProGet 2024. As you described, a lot of the pieces are there - they just aren't wired together very well in some cases. We're working on redesigning this to be more cohesive.

A lot of the existing behavior has to do with performance. For example, /packages/from-purl?pUrl=... is a bit of a "hack" that we used. It's the navigation URL, then then redirects you to the proper URL. This is because finding the URL of a package can be expensive, especially when there are 1000's of packages in a SBOM and multiple candidate feeds for each package. Doing big joins across multiple feeds on the FeedPackages is something we need to very carefully do.

On the same performance note, "Pulling from the source" can be expensive -- especially when you aggregate multiple feeds into one using connectors. So we need to be really careful before doing that.

But like I said, this is something we are redesigning in ProGet 2024; you can think of ProGet SCA features as a "2.0" right now (I guess "1.0" was the old package consumers feature?), and hopefully "3.0" will be a lot closer to getting it right.

Cheers,
Alana