Add TuxCare ecosystem support

[Korulag]

• Prepare your data - refer to the OSV Schema documentation for information on how to properly format the data so it can be accepted.
  Our OSV data source is https://github.com/cloudlinux/tuxcare-osv.

• Create a PR to reserve an ID prefix and define a new ecosystem (example). We review the records you start publishing for OSV Schema correctness and quality as part of reviewing and merging this PR.
  Add TuxCare ecosystem ossf/osv-schema#520

• Prepare and publish your records via a Git repository (example). If this method isn’t ideal, we also support publishing records from REST API endpoints or through a GCS bucket(example).

• To support API querying, please create a PR to extend purl_helpers.py and create a new ecosystem in _ecosystems.py. You can refer to existing examples showing how to implement support for Semver and non-Semver ecosystems.

• Create a PR to start importing the records you are publishing into our test instance of OSV.dev and validate everything is working as intended there.
  feat: Add test ingestion of advisories for Tuxcare ecosystem #4968

• Create a PR to start importing the records you are publishing into our production environment
  feat: Add TuxCare ecosystem ingestion into production #5333

[michaelkedar]

Hi, I made #5231 as a placeholder to allow Tuxcare to be ingested into OSV.dev, but without an implementation, we won't be able to match it on the API.
What versioning rules do Tuxcare packages use? From a quick glance it seems to me to be based on RPM?

[michaelkedar]

Actually, I've noticed that your records use Tuxcare as the ecosystem, while in the schema it is TuxCare

The ecosystem field is case sensitive - could you please update the records?

[Korulag]

@michaelkedar regarding the versioning: it's complicated. TuxCare provides packages for different ecosystems: RPM, DEB, NPM, PyPI, etc., so the versioning may be any combination supported by those ecosystems.
Regarding the case sensitivity: sure, I will update the records.

[another-rex]

One option is to have a suffix on each record's ecosystem (e.g. TuxCare:PyPI), and in the implementation parse the suffix and delegate it to that ecosystem's version matching logic.

[Korulag]

So, in case of current advisories which are for RPM packages the suffix should be TuxCare:RPM then? Or it depends on the distribution under it? In this particular example it's AlmaLinux packages with fixes.
Additionally, if we need to modify the implementation for parsing, could you please point out what exactly needs to be extended?

[another-rex]

We have two paths forward:

• We add version comparison logic to OSV. This allows your records to remain simple (just introduced and fixed), but requires implementing the comparison rules in our backend.

• You provide a full list of affected versions in each record. This avoids any new code implementation on the OSV side but makes your records much larger and harder to maintain.

The exact suffix is up to you, as long as the version comparison code understands the suffix and how to route it.

If you want to go the logic route, the implementation would involve extending osv/ecosystems/... to parse TuxCare versions, and then depending on the ecosystem suffix, and route it to their respective ecosystem comparison logic (e.g., RPM or Deb).
See some of the existing ecosystem version parsing code in there as an example.

[Korulag]

I would prefer to go the logic route then. Given your implementation already has a lot of different version parsers, I basically need to apply them based on the prefix, right?

[another-rex]

Yes, that should be all that's needed :)

[Korulag]

Got it, thank you, I will implement the changes in advisories as well as one in osv-schema to make for proper version parsing

[Korulag]

@michaelkedar I also have a question: I've fixed the advisories to have "TuxCare", for example https://github.com/cloudlinux/tuxcare-osv/blob/main/data/els_os/almalinux9.2fips/CLSA-els_os-almalinux9.2fips-2025%3A1751538844.json, but I don't see the ecosystem to appear on https://test.osv.dev/. Is it an issue with version parsing as we discuss above? Because, for example, Android has the same kind of placeholder yet their advisories exist in the system