Oh ok, I was thinking that we could create a private metadata provider if we want deprecate our own packages without doing it on each feeds. So it will not help me. Thanks

Custom Metadata Provider : https://docs.inedo.com/docs/proget/sca/policies?utm_source=proget&utm_medium=product&utm_campaign=proget24_0#oss-metadata-updating-caching

Hi,

I'm intrusted on how to create a Custom OSS provider. On the documentation you don't explain what is the expected format, if it's an API ...

Could you explain how to implement it correctly please ?

Regards,

Fabrice MÉJEAN

Hi @stevedennis,

I agree with your proposal; it should allow me to meet my current needs.

Regarding obsolescence management, unfortunately, the majority of open-source components do not manage obsolescence, let alone end-of-life dates. That is why we mark all packages older than 3 years as obsolete. This allows us to verify that the open-source project is still alive, and that in case of a vulnerability, we are still able to carry out a corrective version upgrade. I will certainly create another post about this soon, but it gives you something to think about.

I would appreciate a YouTrack reference to track this feature.

Thank you again.

Fabrice MÉJEAN

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

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

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