Hi @stevedennis,

Yes, we are aiming to implement a package approval workflow combined with vulnerability scanning.
Our problem is that for security reasons we are not allowed to expose our internal packages for scanning, hence the primary/public/external feed where scanning occurs separated from the connected secondary/private/internal feeds.

Apparently I have totally missed the Package Consumers functionality, seems to be just the right thing to help tracking vulnerabilities across multiple feeds and applications.
As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and the pgscan publish... command needs to be implemented in every build? That will take som effort to maintain, to be weighed in comparison to chasing vulnerable packages manually. I will bring up the subject with our developers.

Thanks for clarifying!

Regards
/Claes

I'm trying to get my head around the behaviour of License blocking vs Vulnerability blocking.

The example setup:
A primary feed connected to NuGet.org (eg public/external). A secondary feed (eg private/internal) connected to the primary feed.
NuGet.org --connector-> primary --connector-> secondary, as simple as that.

Some license types are blocked by global rules and vulnerability scanning is activated using OSSIndex on the primary feed.

Behaviour:
A package with a blocked license type can't be downloaded (nor promoted), neither from the primary feed nor the secondary. Blocking is applied globally.

But a package with a blocked vulnerability is only blocked from download in the primary feed, the vulnerability is not even visible in the secondary feed, and it's possible to download from there (and promote from both feeds).

Since vulnerabilities most probably show up after you already have downloaded and used packages this behaviour forces you to go through every connected feed or feeds where you maybe have promoted a package, and handle them individually. With a lot of feeds that makes it risky and a lot of work.

Is this intended? Wouldn't it be better to have vulnerabilities work globally like license rules?
Or maybe I have missunderstood something...

The problem occured because some authentication behaviour is changed in ProGet, the solution was to alter the syntax of the Feed API user from [domain][userid] to [userid]@[domain].[top domain]. The old syntax worked before upgrading, no hints in ProGet that this had changed.

We just upgraded ProGet from 5.0.7 to 5.1.19 and now pushing NuGet packages has stopped working with error message "Forbidden ... Response status code does not indicate success: 403 (Invalid API key)."

I have read all documentation and can't figure out why. Same error with old keys and newly registered.
API key logging is on but no logs are produced, have also tried to enable Debug mode in ProGet but can't get any more information.

Product: ProGet
Version: 5.1.19

Hi,
Often when updating Security settings in Administration, ProGet.Service.exe crashes with this error. Any ideas?

Application: ProGet.Service.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
at System.Net.HttpListener.EndGetContext(System.IAsyncResult)
at Inedo.Web.Server.HttpListenerHost.ProcessRequestAsync(System.IAsyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
at System.Net.ListenerAsyncResult.IOCompleted(System.Net.ListenerAsyncResult, UInt32, UInt32)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

Product: ProGet
Version: 5.0.7