Kernel audit categorization

[Kelvinrr]

Description

Our kernels need some accounting for, there seem to exist kernels that we are required to host as they are not hosted in any other obvious place. e.g. reconstructed kernels that do not exist on the obvious mission source (NAIF, JAXA, etc.). I believe it is worth categorizing kernels and doing some kind of accounting for the kind of kernel they are and where they are sourced from.

I believe the easiest way to do this is to categorize based on some regular expression similar how kerneldbgen and spiceql configs work and identify the sources for some ID ranges.

I believe the first step is to identify these patterns and document them in some way such that we can script identifying which ranges currently exist in public sources already identified in our rclone conf and which ones do not.

We might be able to use existing functionality in SpiceQL and/or existing kernel.db files for this as it already tracks some of this information.

Example

some CSV or similar file with information like:

mission	regex	type	quality	filesize	source
MRO	msgr_[0-9]{4}_v[0-9]{2}.bc	CK	Reconstructed	N/A	N/A
MRO	msgr_mdis_sc[0-9]{4}_usgs_v[0-9]{1}.bc	CK	SMITHED	N/A	USGS
...	...	...	...	...	...

doesn't need to be completely filled in for the DOD of this issue, but by explicitly writing down the categorizations now we can use that as a jumping point for a potential effort later to fill in all the metadata and determine how to maintain it if it is of value. Potentially we can do this on an individual kernel level rather than using regex as those can be really inconsistint.

[github-actions[bot]]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[Kelvinrr]

still a relevant issue

[github-actions[bot]]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

If you want to participate in our support prioritization meetings or be notified when support sprints are happening, you can sign up the support sprint notification emails here.

Read more about our support processs here

[Kelvinrr]

bump