Expose API endpoints as a `Plugin`

[oxisto]

Current Behavior

I am currently trying to migrate the CSAF extensions to the new plugin system (which overall I think is a good idea). However, we do have certain "csaf specific endpoints", which we currently need to place directly in the apiserver and then basically call functions of the plugin - which is a little bit cumbersome.

Proposed Behavior

I wonder if it would be possible to define new API routes directly in the plugin - maybe "forwarded" by the /v2 extension endpoint.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

Since the CSAF feature appears to be rather extensive, I'd recommend against making it a plugin for the time being.

Even if we added the ability to define API resources, you'd still need a way to access the database without restrictions (which we don't want for plugins), define entirely new UI interfaces (to manage CSAF registries) etc.

I would not rule out us eventually adding support for plugin-defined endpoints, but I believe this needs more elaborate planning and design. In particular WRT how this would interact with access control.

Try building the CSAF feature into the API server and see how far you get, rather than attempting to shoehorn the entire thing into a plugin. If you encounter cases where leveraging the plugin system makes sense, then let's have another look.

[nscuro]

That aside, if you could share some more information as to what you were planning to do, it would help a lot in understanding where the system's current limitations are.

[oxisto]

Since the CSAF feature appears to be rather extensive, I'd recommend against making it a plugin for the time being.

Even if we added the ability to define API resources, you'd still need a way to access the database without restrictions (which we don't want for plugins), define entirely new UI interfaces (to manage CSAF registries) etc.

I would not rule out us eventually adding support for plugin-defined endpoints, but I believe this needs more elaborate planning and design. In particular WRT how this would interact with access control.

Try building the CSAF feature into the API server and see how far you get, rather than attempting to shoehorn the entire thing into a plugin. If you encounter cases where leveraging the plugin system makes sense, then let's have another look.

Thanks! I am currently trying to use more features of the plugin system, e.g., actually storing config related things (i.e., the list of aggregators) and store them using the runtime configuration rather than storing them as new database entries - mainly because of the restriction that I cannot use the database in a plugin. But I think this actually makes sense, but I basically "need" to expose additional endpoints to the UI to add/edit and manage those kind of resources. Currently, I am serialising them as a JSON string, similar to what the OSV plugin does with its watermark.

[oxisto]

Hmm I wonder whether we are running into the restriction of having the config value as a varchar(1024) if we store a lot of providers as a JSON in there. Is it planned or possible to extend this value?

[nscuro]

I don't see a problem in extending the size limit via DB migration. The bigger challenge would be the UX of editing this data in the UI IMO.

For simple cases I was thinking we could use https://codemirror.net/ to render JSON in a somewhat pleasant way, with indentation and ideally feedback when invalid JSON is entered.

[oxisto]

I don't see a problem in extending the size limit via DB migration. The bigger challenge would be the UX of editing this data in the UI IMO.

The UI/UX part we already have. So would you rather prefer to store these kind of informations (mainly the list of CSAF sources, providers, aggregators) as plugin-configs or as dedicated DB entities? It is basically a structure of

• name
• url
• ID
• whether its a provider or an aggregator
• lastFetched

So my new approach would be to store them in the runtime config. If that would work I would try to implement the CSAF vulnerability mirroring as a plugin.

[{"id":0,"name":"CERT-Bund CSAF Aggregator","url":"https://wid.cert-bund.de/.well-known/csaf-aggregator/aggregator.json","aggregator":true,"enabled":false,"lastFetched":null},{"id":1,"name":"test","url":"siemens.com","aggregator":true,"enabled":true,"lastFetched":null}]

[nscuro]

Yeah give that a try and see if you run into any issues. But in principal that sounds fine to me.

[oxisto]

Yeah give that a try and see if you run into any issues. But in principal that sounds fine to me.

Sorry for highjacking this issue, unfortunately I cannot change the size of the config field that easily, since it seems that a view depends on it :(