Posts made by apxltd

It seems like NuGet.org now finally supports it! So we will too; I filed PG-1246 to add it to a future maintence release.

Good question.

Regarding Vor Security, that was a recent acquisition by Sonatype, and it's being transitioned into a new service called OssIndex. Sonatype plans to keep this going for the foreseeable future, and we have verified this with Ken Duck (formerly of Vor Security, now Sonatype employee). ProGet will continue to support it (we are renaming it as well).

Moreover, we are planning to work with Sonatype to better integrate their broader services (vulnerability scanning) with ProGet. We are also investigating Blackduck integration, though we're not entirely sure how it would work with ProGet.

Regarding "developing our own"... broadly speaking, there are two types of vulnerabilities scanning:

• static analysis - analyzing actual code or binaries to look for patterns (buffer overflow, etc); this is done "on your own software"
• repository/database - looking at public databases like NVD, CVE, etc. for vendor- or third-party documented vulnerabilities reported for a known, published piece of software

We don't believe that static analysis has a place in a package manger; there are a handful of tools that can scan your codebase directly for this.

As for repository/databases, it's not really bout "finding" vulnerabilities in software, it's more about "aggregating databases" and then translating those into machine-readable formats. This is what Sonatype, Whitesource, etc., do, and we think more vendors will continue to innovate in this space.

But the "repository" and "scanning" are two different problems, and you should pick the best of both problems; it would almost be like saying "Microsoft makes Office, may as well use Visual Studio and .NET".

ProGet has the extensibility support for this already, so we should be able to integrate with new providers as they come up,

The behavior your describing is to be expected; basically the API acts as an impersonation token, meaning... if you supply an apikey, and its associated with a user, then it's as if you logged in as that user.

So in this case, try this:

1. create a user called ApiUser, and give ApiUser access to myFeed as desired
2. go to the APIKeys and Access Logs screen.
3. create a key and tick Feed API and set Feed API user to ApiUser

Assuming myFeed doesn't allow anonymous access (you will need to restrict this from permissions page), then you will need to provide an api key or username/password to access that feed.

In this case, just use the key you created.

Hope that helps!

It doesn't, but I think we should add it to the Release & Package Deployment .. so I added BM-3149

So, it will come in a future maintenance release, since it's additive and seems to pose minor risk.

There isn't currently, but there will be soon! Please see PG-1221

I can't imagine any reason at all this wouldn't be done, and it can go it the next maintenance release assuming it passes code review etc!

Thanks much for the specific suggestion!

Mostly it's goign to be the PlanVersions table. Plan_Bytes is UTF8-encoded , so you can do "CAST(Plan_Bytes as VARCHAR(MAX))". The ConfigurationFileInstances table may reference it, if you use configuration file assets. IssueSources are another destination.

Note you should never directly update the database.

Hey Clint;

This was intentional in the infrastructure sync; credentials are a bit trickier, because of the encryption key and fact that some credentials aren't supported.

That said, this is definitely on our roadmap and will (likely) come in the form of a new (free) product that manages multiple instances of our tools:

• users and permissions
• licenses
• resource credentials
• infrastructure (?)
• other settings?

In the mean time, it's possible to do with a database script / simple tool that just updates rows from one database to another (ResourceCredentials table). We can certainly help with that if needed.