Request for Creation of API for Package Auditing Before Dependency Restoration

fabrice.mejean

Hello,

I would like to submit a request for the creation of an API dedicated to auditing packages prior to the restoration of dependencies within our software factory. Currently, we utilize Native APIs to validate the dependencies used by an application before restoration. However, this approach has certain limitations that lead us to seek a more efficient solution.

Below are the key functionalities we would like to see implemented in this new API:

Verification of Package Promotion:

Currently, the existing API verifies if the package has been promoted, but it does not confirm whether the package is still present in the target. We would like a more thorough method that utilizes the package API to verify the presence of the package.

Status of Obsolete Packages:

There is currently only a "set package status" API, but no "get package status." We need functionality that allows us to retrieve the status of packages to identify those that are obsolete or blocked from downloading.

Vulnerability Checks:

We need to verify package vulnerabilities and indicate those that are blocked from downloading due to critical vulnerabilities, along with their severity ratings.
The goal of this API would be to perform a complete audit of dependencies before the build process, preventing issues during package restoration. This would enable developers to quickly diagnose and resolve installation problems, ultimately saving them a significant amount of time.

Additionally, I want to highlight that the current audit API requires the registration of a build to function, which is not feasible in our context, especially for builds that have not yet been initiated.

Thank you for considering this request. I am available for any further information or to discuss the details related to this proposal.

Best regards

Fabrice MÉJEAN

stevedennis

Hi @fabrice-mejean_5174 ,

Thanks for the suggestion; to help move this forward, we thought about this from a technical standpoint. We're a little hesitant to call the command pgutil packages audit since there's already an audit command for builds and vulnerabilities.

One idea is to deprecate pgutil vulnerabilities audit and call it pgutil packages audit instead.

In any case, this new command is a combination of pgutil builds audit and pgutil vulns audit.

The pgutil packages audit command would input a project, something like this:

pgutil packages audit --project=c:\projects\MyProject.csproj

Behind the scenes, pgutil would parse and POST a packageset:

POST /api/sca/audit-packages
[ 
    {
        "name": myPackage
        "version": 1.2.3
        "type": "nuget"
    },
    {
        "name": myPackage
        "version": 1.2.3
        "type": "nuget"
    }
]

The API would return an array I suppose (we don't have any samples for that, but it's a serialized BuildInfo.cs), and the end result would look like this:

$> pgutil packages audit --project=c:\projects\MyProject.csproj

Parsing MyProject.csproj... found X packages.

Azure.Core-1.35.0
 Compliance      : Compliant
 License         : MIT
 Vulnerabilities : None

Microsoft.Extensions.Configuration.EnvironmentVariables 8.0.0 
 Compliance      : Noncompliant
 License         : MIT, Apache-2.0
 Vulnerabilities : PG-123456 (High)
   the vulnerability title of this vulnerability goes here

The API could obviously contain more info. It's documented via serialized .cs classes here:
https://github.com/Inedo/pgutil/tree/thousand/Inedo.ProGet

Thanks,
Steve

fabrice.mejean

Hello @stevedennis ,

Thank you very much for taking the time to respond to my request. Your proposal aligns well with my needs, but I would like to point out that it lacks the retrieval of the "package status" (PackageStatus object).

Regarding the pgutil vulnerabilities audit command, I understand that there is a suggestion it might be redundant. However, I don't believe it would actually create a duplication, especially if it can execute more quickly and meet specific requirements.

Additionally, I’ve noticed that there isn’t a command to check if a package has been promoted, even though the API for it exists (https://docs.inedo.com/docs/proget/api/packages/promote/promotion-query). Would it be possible to add this functionality? Also, if we could verify that the package is still present in the destination repository, that would be a significant advantage.

Thanks again for your help!

Best regards,

Fabrice MEJEAN

stevedennis

Hi @fabrice-mejean,

Good point, it would not have PackageStatus. So let's jus say we add that in, like this:

Azure.Core-1.35.0 (Deprecated)
 Compliance      : Compliant
 License         : MIT
 Vulnerabilities : None

Obviously the API would return it in a structure manner, and it could also show downloads etc.

However, all this data (including package status) means we need a feed in context. So the command would have to look like:

pgutil packages audit --project=c:\projects\MyProject.csproj --feed myFeed

I'm not sure how I feel about that. Packages can be in multiple feeds, and often times users build from multiple feeds.

Anyway.... I have a new idea... what do you think about this:

pgutil packages metadata --feed=myNugetFeed --package=myNugetPackage --version=1.2.3

That could return the normal metadata, but also server-side metadata (package status, downloads, etc).

I guess it would require multiple API calls, though I doubt that's going to cause any more performance overhead than a "bulk" kind of API call that just "looped" over packages and looked them up in the same manner.

Let me know your thoughts.

Thanks,
Steve

fabrice.mejean

Hello @stevedennis ,

You raise a good point. Indeed, we should consider adding the 'feed' parameter, as the concept of obsolescence is tied to it. This begs the question of whether it should remain this way or if it should be managed more globally, similar to how vulnerabilities are handled. However, that would go beyond a simple API addition.

On the other hand, I am absolutely fine with making multiple calls to achieve my goals, as long as ProGet can handle the load.

Additionally, I would like to ask about the use of 'pgutil packages audit' and whether it indicates compliant or non-compliant. Does this status utilize all the rules (license, vulnerability, and others), and is there a plan to provide insights into the reasons behind the result? If it takes into account all the rules, then the 'other rules' are dependent on the feed, making the 'feed' parameter essential.

Thank you for your thoughts on this matter. Looking forward to your feedback!

Best regards,

Fabrice MEJEAN