Hi Roger,
A quick update - we discussed this on the tech call and Bill is pulling together a proposal, so there's a chance this could make it into SPDX 2.0. There should be an SPDX bug to track the enhancement added soon. Gary From: Meier, Roger [mailto:[email protected]] Sent: Wednesday, March 19, 2014 4:53 AM To: Gary O'Neall; 'Bill Schineller'; 'Jeremiah Foster'; [email protected] Subject: RE: software identifiers / traceability...RE: RDF Terms for the SPDX 2.0 model Hi all Yes, might be too late for 2.0. Im really sorry for bringing in that topic late and being unable to join the collaboration summit next week. I would like to highlight the traceability of software assets across software management systems. A use case is link assets across security management and licensing systems. This site provides more details on CPE https://cpe.mitre.org/specification/ which is primarily used within the security context and allows fine-grained definitions not only vendor / product /version . It goes much further than maven naming and co. Here are some examples of CPE Names: - cpe:/o:linux:linux_kernel:681a287 git hash created by `git rev-parse --short HEAD` - cpe:/o:linux:linux_kernel:681a287:*:*:arm - cpe:/o:linux:linux_kernel:3.13 - cpe:/a:apache:thrift:0.9.1 - cpe:/a:busybox:busybox:1.9.2 Available Attributes that end up in a CPE formatted Name (cpe:/a:busybox:busybox:1.9.2): Part: a Vendor: busybox Product: busybox Version: 1.9.2 Revision: Edition: Language: Software Edition: Target Software: Target Hardware: Other: See here: http://web.nvd.nist.gov/view/cpe/detail?cpeId=173193 <http://web.nvd.nist.gov/view/cpe/detail?cpeId=173193&searchText=cpe%3A%2Fa% 3Abusybox%3Abusybox%3A1.9.2&includeDeprecated=false&searchChoice=name&page_n um=0&cid=9> &searchText=cpe%3A%2Fa%3Abusybox%3Abusybox%3A1.9.2&includeDeprecated=false&s earchChoice=name&page_num=0&cid=9 All the best! -roger From: [email protected] [mailto:[email protected]] On Behalf Of Gary O'Neall Sent: Freitag, 14. März 2014 19:11 To: 'Bill Schineller'; 'Jeremiah Foster'; [email protected] Subject: RE: software identifiers / traceability...RE: RDF Terms for the SPDX 2.0 model Hi all, We have discussed this some - it has also come up as a potential project for OMG to tackle. I agree with Bill's proposal in the subsequent thread to adopt existing schemas that have already been defined. Not sure if I want to tackle this in 2.0 since we have a lot of work remaining. Perhaps a future release? Gary From: [email protected] [mailto:[email protected]] On Behalf Of Bill Schineller Sent: Friday, March 14, 2014 8:15 AM To: Jeremiah Foster; [email protected] Subject: software identifiers / traceability...RE: RDF Terms for the SPDX 2.0 model Hi All, Thanks Gary for the modeling updates, and Roger, Jeremiah for raising the topic of traceability and how to universally refer to specific software assets. I'm in the camp that believes this is a critical Use Case remaining to be addressed within SPDX and other contexts for how to refer to software assets. Such that someone picking up an SPDX document containing an analysis of a codebase with lots of files, some of which are directly taken from releases of OSS projects, can not only say their codebase contains a file/library (re?)named 'v2.jar' with sha1='4c490d7d15919d9927a9722c73a5a473af92163f' under license 'Apache-2.0', but can express that the jar was taken from the Maven repository where its unique identifier is 'jaxb:activation:1.0.2'. (within the 'namespace' "Maven" the unique naming convention is specified by http://maven.apache.org/guides/mini/guide-naming-conventions.html) Or that they included Debian package 'acl2-books-source_4.2-1_all.deb' with sha1='d9d340cb55b681972e288d792a81295e1ede7cd0' and express that it was taken from Debian package management system where the naming convention is <foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb per http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html Similarly if they take a Ruby gem from rubygems.org (<package>/<version>), or a Nuget package from nuget.com (<package>/<version>), or a snapshot of source code from github.com (<owner>/<repo>/<commithash>)? The point: specify the 'namespace' within which the identifier is unique, and an understood naming convention within that namespace that is well known (machine readable). I don't know if a catalogue of all the namespaces and the unique naming conventions within them has been published, and if not I think SPDX can write this into specification. In my opinion, Mitre CPE (vendor / product /version ) doesn't quite fit the bill. The ISO/IEC 19770-2:2009 seems like a good but lofty concept. If my quick read of http://en.wikipedia.org/wiki/ISO/IEC_19770 is correct, it centers around a central issuer of IDs http://tagvault.org/swid-tags/ and costs money, so I think it will be slow to adoption. My proposal is sort of an 'if you can't beat them, join them' approach: adopt the unique identification schemes already in place per namespace / site / community. Attached cartoon you may find humorous / relevant (from http://xkcd.com/927/) - Bill _____ From: [email protected] [[email protected]] on behalf of Jeremiah Foster [[email protected]] Sent: Friday, March 14, 2014 4:07 AM To: [email protected] Subject: Re: RDF Terms for the SPDX 2.0 model On Fri, Mar 14, 2014 at 8:00 AM, Meier, Roger <[email protected]> wrote: Hi Gary Thank you for this great work! I recently had a discussion on traceability of software components across software management platforms. Currently I see two directions in that area: - Common Platform Enumeration - https://cpe.mitre.org/specification/ - ISO/IEC 19770-2:2009 Did you discuss such a use case already? Personally I think it would be worth to add a Package CPE Name attribute to the Package Information section of SPDX, e.g. Package Name: Linux Kernel Package Version: 3.2.17 Package CPE: cpe:/o:linux:linux_kernel:3.2.17 What is the rationale for doing this? On a typical GNU/Linux system this information is already available via other means. What use case does SPDX solve here? Regards, Jeremiah
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
