Clarify usage of version ranges

[tschmidtb51]

I strongly believe that the easiest way for a customer is, not having to worry about version ranges. Nevertheless, I also understand the PSIRTs working hard to compile advisories to the best of their knowledge. And sometimes PSIRTs don't know exactly which versions are affected.

Therefore, I suggest the following approach:

1. Introduce a new category product_version_range. This one holds all version ranges while the existing product_version only holds single versions. Write a mandatory test to enforce it. (Could be something like "check whether all versions, <, <=, prior, later exist in the value.)
2. Clarify, how version ranges should be represented in CSAF. An approach could be to specify:

• if possible: use vers
• if vers is not possible: use a specifier that follows the rules of vers as closely as possible (then the programs can make a best effort guess whether it is in range)

Thoughts?

Flagging @santosomar, @tolim, @mprpic, @wrideout for attention.

[rjb4standards]

I agree with Thomas. The use of ranges was problematic when I was considering the use of VEX to serve as a CARFAX for SBOM concept. Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: ***@***.***> ***@***.*** Tel: +1 978-696-1788 From: tschmidtb51 ***@***.***> Sent: Wednesday, January 26, 2022 3:31 PM To: oasis-tcs/csaf ***@***.***> Cc: Subscribed ***@***.***> Subject: [oasis-tcs/csaf] Clarify usage of version ranges (Issue #392) I strongly believe that the easiest way for a customer is, not having to worry about version ranges. Nevertheless, I also understand the PSIRTs working hard to compile advisories to the best of their knowledge. And sometimes PSIRTs don't know exactly which versions are affected. Therefore, I suggest the following approach: 1. Introduce a new category product_version_range. This one holds all version ranges while the existing product_version only holds single versions. Write a mandatory test to enforce it. (Could be something like "check whether all versions, <, <=, prior, later exist in the value.) 2. Clarify, how version ranges should be represented in CSAF. An approach could be to specify: * if possible: use vers <https://github.com/package-url/purl-spec/blob/version-range-spec/VERSION-RANGE-SPEC.rst> * if vers is not possible: use a specifier that follows the rules of vers as closely as possible (then the programs can make a best effort guess whether it is in range) Thoughts? Flagging @santosomar <https://github.com/santosomar> , @tolim <https://github.com/tolim> , @mprpic <https://github.com/mprpic> , @wrideout <https://github.com/wrideout> for attention. — Reply to this email directly, view it on GitHub <#392> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFI3NAWC4CZV56IFJ2OIK3UYBKW5ANCNFSM5M4BBMDQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tschmidtb51]

Here are some examples. Currently, we have:

Example 1: for Apache TomEE

{
   "name": "8.0.0-M1 - 8.0.1",
   "category": "product_version",
   // ...
}

Example 2:

{
   "name": "All versions < V3.0.29",
   "category": "product_version",
   // ...
}

Example 3:

{
   "name": "V3.0, V4.0, V4.1, V4.2",
   "category": "product_version",
   // ...
}

My suggestion would represent them as:

Example 1: for Apache TomEE

{
   "name": "vers:tomee/>=8.0.0-M1|<=8.0.1",
   "category": "product_version_range",
   // ...
}

Example 2:

{
   "name": "<3.0.29",
   "category": "product_version_range",
   // ...
}

Example 3: (those are single product versions and should be represented as such.)

{
   "name": "V3.0",
   "category": "product_version",
   // ...
},
{
   "name": "V4.0",
   "category": "product_version",
   // ...
},
{
   "name": "V4.1",
   "category": "product_version",
   // ...
},
{
   "name": "V4.2",
   "category": "product_version",
   // ...
}

Note: I also suggest to remove the V if its not part of the version string. But that's up to the author to decide.

[tolim]

The approach looks good to me. However, I do not like the following statement:

if vers is not possible: use a specifier that follows the rules of vers as closely as possible (then the programs can make a best effort guess whether it is in range)

Any deviation from vers would be a problem for tool-based advisory consumers. Even without using product_version_range, a CSAF document may specify a version range using prose. Do we really need that statement?

[rjb4standards]

IMO a best guess = uncertainty which is not helpful. Explicit version identifiers would remove the uncertainty that range introduces.

Based on my experiences, a version identifier isn't guaranteed to be monotonically increasing; some vendors use hash values as version identifiers.

[sparrell]

I recognize the desire for "all" as a version range. As a developer, I even recognize how much easier it makes my life. E.g. I know the websites I wrote are not affected by log4j since I don't use java, so "all" is just easier than figuring out my versions. However wearing my CISO hat, I don't trust "all". What if the next version of my website does include java? What if I forgot about a product or version? What if I consider a particular product/version out of scope since I no longer support it, but some customer is still using it? I am much more in favor of explicit lists.