Request for Lowercase ( even Space-Free ) Abbreviation for Query API Eco Name

[edwinjhlee]

Description:

The current query API eco name contains uppercase letters and spaces, making it cumbersome to use in command-line calls. For improved usability and consistency with other API conventions, we request a lowercase ( even space-free ) abbreviation for the eco name.

Benefits:

Improved Command-Line Usability: A concise abbreviation will make it easier to type and remember when using the API in scripts and command-line tools.

It will be even better if the naming is (partly) consistent with CPE23 standard.

Example:

If the current eco name is "Rocky Linux", a possible abbreviation could be "rockylinux", or even "rocky", or "rocky:linux" (cpe23)

Request:

We kindly request the development team to consider adding a lowercase, space-free abbreviation for the query API eco name. This will significantly enhance the user experience.

[edwinjhlee]

https://x-cmd.com/mod/osv

The current way to query OSV using x osv q -p OSS-Fuzz,jq is a bit cumbersome. It would be much better to use x osv q -p oss-fuzz,jq.

We can add the name mapping in the client ( I might probably do it in the next week ).
However, it would be more beneficial if OSV officially provided a standard name mapping to avoid potential future confusion.

[edwinjhlee]

Here is the grype --distro ID:

https://pkg.go.dev/github.com/anchore/grype/grype/distro#RockyLinux

[andrewpollock]

Based on https://github.com/x-cmd/x-cmd/tree/main/mod/osv/lib I think this is more appropriate as an FR on the OSV.dev API itself, in the OSV.dev repo, so I'll move it over there...

[oliverchang]

Hi there, thanks for the feature request.

Our current position is this kind of fuzzy matching is best done on the client side. The reasoning is:

• The OSV Schema provides a canonical formatting of ecosystem names, and we'd like to not encourage more ways to diverge from it and reduce the consistency of ecosystem names in the OSV platform.

• It's unclear how many users this would benefit, since most of our users would likely be using the API in an automated setting (e.g. a vulnerability scanner), rather than users typing on a command line.

We'll re-assess this if we see more requests from our users for this.