osv.dev Support openEuler datasource

Hi all,

I'm from openEuler security team. We're an open source community aiming to build a secure and trusted linux distro. We're currently building our security database and exporting security advisories in OSV Schema.

Samples are now available in the repo: https://github.com/kirigiricloud/oesa_osv_samples Full data will be published soon in openEuler repo: https://repo.openeuler.org/security/data/osv/

We would like OSV to validate and ingest our data, and we're ready to discuss the remaining onboarding steps.

Thanks for your consideration! Any suggestions would be greatly appreciated.

Tony

[x] Prepare your data - refer to the OSV Schema documentation for information on how to properly format the data so it can be accepted.
[x] 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. [ossf/osv-schema#358]
[ ] 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). [WIP]
[ ] 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. [WIP]
[ ] 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.
[ ] Create a PR to start importing the records you are publishing into our production environment

Jun 12 '25 09:06 kirigiricloud

Thanks for contributing! We'll take some time to review the schema change PR. Please let us know if you encounter any issues with the data source adding process.

Jun 13 '25 00:06 hogo6002

Thanks for contributing! We'll take some time to review the schema change PR. Please let us know if you encounter any issues with the data source adding process.

Hi! @hogo6002 @oliverchang

Thanks for reviewing and merging the schema PR, and sorry for the late update. We've just finished testing and our OSV data is now live at https://repo.openeuler.org/security/data/osv/

I've also submitted the remaining PRs. Could you take a look when you get a chance? Thanks!

Aug 07 '25 08:08 kirigiricloud

Hello, looking at the records in the test instance, we found a few validation errors:

One is that there are a bunch of range entries that are empty, see : https://repo.openeuler.org/security/data/osv/OESA-2025-1068.json

Aug 12 '25 05:08 another-rex

We are also noticing that there are a bunch of records returned in the all.json endpoint, that does not exist when we try and query them. E.g.

OESA-2025-1991 shows up in all.json, but 404s when we try this link:

https://repo.openeuler.org/security/data/osv/OESA-2025-1991.json

Aug 13 '25 04:08 another-rex

Hello, looking at the records in the test instance, we found a few validation errors:

One is that there are a bunch of range entries that are empty, see : https://repo.openeuler.org/security/data/osv/OESA-2025-1068.json

Hi there,

Thanks for the feedback and for merging the PRs! There were some issues with the OSV advisories generation tool and publish system - sorry for the chaos this caused.

I've updated the files mentioned and the issues have been resolved. If anything else comes up, feel free to reach out to me again.

Aug 13 '25 09:08 kirigiricloud

FYI you can see the records populated here in our test instance now: https://test.osv.dev/list?ecosystem=openEuler , please take a look to see if everything looks good to you!

Aug 14 '25 00:08 another-rex

Hello,

Thanks for the update! The openEuler records in the test instance look good to me. We published some new records last Friday and they're showing up correctly.

We noticed the display issues mentioned in #3812. It seems fixed in #3813 for openEuler now, but the GIT ecosystem records still persist just FYI. For example, CVE-2025-8800.

Aug 18 '25 03:08 kirigiricloud

Hi, I noticed a suspiciously long package name in the osv.dev data set, and it belongs to an openEuler record.

https://osv.dev/vulnerability/OESA-2021-1474

There is a single item in the "affected" array, with the following package name (all one string):

log4j,mybatis,netty,springframework,wildfly-security-manager,wildfly-elytron,wildfly-build-tools,wildfly-common,wildfly-core,thrift,json-lib,datanucleus-core,jgroups,mx4j,jboss-logging,infinispan,datanucleus-rdbms,avalon-logkit,datanucleus-api-jdo,avalon-framework,HikariCP,metrics

Should this actually be separate items in the affected array, each with its own package?

Edit: Same thing, but in the source database: https://repo.openeuler.org/security/data/osv/OESA-2021-1474.json

Sep 04 '25 00:09 chrisimcevoy

Hi! Thanks for the report.

We've investigated the long-name records (OESA-2021-1467, OESA-2021-1474, OESA-2021-1481). These 2021 records were inconsistent with our current security advisory generation logic (one component per advisory). I've updated these records to separate packages into individual affected items.

The corrected data are now in the database.

Sep 05 '25 08:09 kirigiricloud

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.

Nov 04 '25 09:11 github-actions[bot]

Automatically closing stale issue

Nov 18 '25 10:11 github-actions[bot]