In both SPDXv2 (which the initial email pointed to) and SPDXv3, the license version information is optional. Therefore, when someone does not know a package version, the property/field can be omitted.
What would the meaning of “NOASSERTION” be? In other words, what is the “known unknown” case that Gary speaks about? I should point that in current SPDXv2, in similar fields like concludedLicense, we already have that “If the field is not present in a package, it implies an equivalent meaning to NOASSERTION ” Regardless of this, I hope that we all agree that having a value of NOASSERTION as packageVersion means that the SBOM including this does NOT meet NTIA’s minimum requirements. -- zvr From: [email protected] <[email protected]> On Behalf Of Gary O'Neall Sent: Saturday, 19 August, 2023 00:34 To: [email protected] Cc: [email protected]; 'SPDX Technical Mailing List' <[email protected]>; 'Emrick Donadei' <[email protected]>; 'Tyler Pirtle' <[email protected]> Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field My initial thought is that NOASSERTION should only be applicable to certain fields where a “known unknown” assertion is valuable. In the RDF / OWL / semantic web SPDX spec., we would add a NOASSERTION value in the range of possible values for that property. This would allow computer semantic reasoning to answer questions like “what packages in this distribution have ‘known unknown’ version?”. The downside is that we would need to do more updates to the spec. Best, Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Brandon Lum via lists.spdx.org Sent: Friday, August 18, 2023 10:38 AM To: Gary O'Neall <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; SPDX Technical Mailing List <[email protected]<mailto:[email protected]>>; Emrick Donadei <[email protected]<mailto:[email protected]>>; Tyler Pirtle <[email protected]<mailto:[email protected]>> Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field I think one follow-up question is around whether it is recognized in the specification.. For example, package supplier (https://spdx.github.io/spdx-spec/v2.3/package-information/#75-package-supplier-field) it is stated clearly that NOASSERTION is within the format, but not in the case of VersionInfo I think the question is NOASSERTION usable in any text field? Or does there need to be explicit indication within the spec where a NOASSERTION can be used? On Fri, Aug 18, 2023 at 1:22 PM Gary O'Neall <[email protected]<mailto:[email protected]>> wrote: My opinion is that it would be useful to be able to express a “known unknown” on the version if the version can’t be determined. I also agree we should strive to always have a version available. This is especially important in tracking vulnerability information. I just know that there are several situations where this just isn’t possible (e.g. source files copied from an upstream project where no one kept track of the original version). It would be better to have the imperfect package information than no information at all. The NOASSERTION approach seems like a consistent way to represent the “known unknown”. Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Dick Brooks Sent: Friday, August 18, 2023 9:53 AM To: [email protected]<mailto:[email protected]>; 'SPDX Technical Mailing List' <[email protected]<mailto:[email protected]>> Cc: 'Emrick Donadei' <[email protected]<mailto:[email protected]>>; 'Tyler Pirtle' <[email protected]<mailto:[email protected]>> Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field Brandon, REA applies the NOASSERTION value when a PackageVersion is indeterminant, based on guidance provided by the NTIA work effort. This is not an issue with “file components” as no version is required. Thanks, Dick Brooks [cid:[email protected]] [cid:[email protected]] Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report!<https://reliableenergyanalytics.com/products> ™ http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/> Email: [email protected]<mailto:[email protected]> Tel: +1 978-696-1788<tel:(978)%20696-1788> From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Brandon Lum via lists.spdx.org<http://lists.spdx.org> Sent: Friday, August 18, 2023 12:16 PM To: SPDX Technical Mailing List <[email protected]<mailto:[email protected]>> Cc: Emrick Donadei <[email protected]<mailto:[email protected]>>; Tyler Pirtle <[email protected]<mailto:[email protected]>> Subject: [spdx-tech] NOASSERTION on PackageVersion field Hi, In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into situations where the version information of a package is unknown. What comes to mind is to set the version to NOASSERTION. However, this is not currently spelt out in the spec (https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field). Although semantically, in terms of usage of information, it should be similar, it still lacks the ability to say that "This information is incomplete", with exception of having NOASSERTION be set on the DEPENDS_ON relationship more broadly - which may perhaps be a different discussion altogether. Wanted to get thoughts on this. Cheers Brandon Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5307): https://lists.spdx.org/g/Spdx-tech/message/5307 Mute This Topic: https://lists.spdx.org/mt/100823660/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
