[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Analysis of SPDX compatibility with current SBOM proposal



Hello

My generation tool is an R script now available in GitHub buildDocxAndXmi.R
It needs only be executed. 
I run it with R version 3.6.0 from within Rstudio (either Rstudio desktop on Windows and Mac OS X, either Rstudio Server on a Centos 7 linux server).
The tool can handle multiple locations to try multiple model files. Currently, it expects files in ./model/plb/ subdirectory.


Philippe-Emmanuel 

From: Kay Williams Sent: Thursday, January 09, 2020 10:59 PM
To: Gary O'Neall; Philippe-Emmanuel Douziech; Subject: RE: Analysis of SPDX compatibility with current SBOM proposal

Thanks Gary,

 

Philippe-Emmanuel, would it be possible to make the tools for generating the model and documentation public? Specifically, can we put tooling and instructions on GitHub?  This would allow any of us to make local changes, experiment, and push local changes for acceptance to the master branch.

 

Is there a better way?

 

Thanks,

Kay

 

From: Gary O'Neall
Sent: Thursday, January 9, 2020 1:30 PM
To: Kay Williams Subject: RE: Analysis of SPDX compatibility with current SBOM proposal

 

Hi Kay,

 

Good question on tools improving collaboration. 

 

I like the work that Philippe has done with the spreadsheet and I think that using the Github issues will be quite helpful.

 

There are two areas I find challenging in collaborating on the model. 

 

One is tools.  I would like to re-use the work Phillippe, William and others have done to offer improvements to the model, but I haven’t found a way to import the XMI documents.  I have tried using GenMyModel, but the imported XMI document just shows up blank.  This is likely my inexperience with the tool, but it is a challenge.

 

Another area is understanding the changes changes to the model.  For example, the model diverged from SPDX with some recent changes, but I wasn’t able to find out why the changes were made.  This will be partially helped by tracking issues in Github.  Another way this could be improved is adding commit history with granular changes and summary comments.  If the tools allowed for it, we could even open it up to Github pull requests where anyone could submit the changes in addition to submitting the issues.

 

Thanks,
Gary

 

 

 

Thanks Philippe – having these organized in a table really helps.

 

BTW – the generated 3T-SBOM-EMS file on the Google Drive looks like it may be an old version.  The modification history in Google Docs doesn’t show any change, but a number of the issues I have identified seem to have been resolved, but the document now appears inconsistent with some of the diagrams (e.g. https://drive.google.com/drive/u/1/folders/1q9v4y6MJBagQn42DMIqwSKU6lerrKWCj).  I’m working from the word doc downloaded from the Git repository: https://github.com/cdfoundation/sig-security-sbom/blob/master/modeling/generated_3T-SBOM-EMS.docx

 

BTW – from a quick glance, the version that is on Google docs does not have many of the issues identified in my analysis.

 

I’ll go through my old analysis and move them over to the sheet or add issues to the git repo.

 

Gary

 

 

From: Philippe-Emmanuel Douziech < Sent: Thursday, January 9, 2020 12:06 AM
To: <
 

Hello

 

As discussed yesterday, I produced tables to track change propositions (and justifications)

Best regards

 

Philippe-Emmanuel

 

From: Philippe-Emmanuel Douziech
Sent: lundi 6 janvier 2020 08:34
To: Gary O'Neall < Subject: RE: Analysis of SPDX compatibility with current SBOM proposal

 

Hello and a happy successful 2020 to all!

@Gary O'Neall Thanks for your work, I’ll have a look at your document before our weekly call.

On my side, I worked on a JSON schema: https://drive.google.com/open?id=1vjnh8FD3GXTqXQ7eK-hD1WfQgm6Y0lPD / https://github.com/cdfoundation/sig-security-sbom/blob/master/modeling/generated_3T-SBOM-EMS.schema.json (for which I also had to change type attributes to specialized xxxType).

Then, @William Cox, I saw a copy of the generated DOCX in the Google Drive ( https://drive.google.com/open?id=1N-QwH9zN-hX4N3NmtHjzG3k4dP25jTiN ) but I didn’t see the updates. Could you tell me the differences?

Thank you

Philippe-Emmanuel

 

 

Greetings all,

 

I completed a line by line comparison of the SPDX 2.2 UML model with the current SBOM model.  A draft of the results of the analysis are here: https://docs.google.com/document/d/1s4TQN6DgfF6rup_5aQbySQpVrdaaK24ngnRmwqsmmXs/edit?usp=sharing

 

Feel free to review and comment.

 

I realize the document may not be very clear in places – it was taking me a lot more time than I had budgeted for the exercise and I thought it would be better to just get out something of a draft rather than waiting until it was more polished.

 

I found a number of incompatibilities; many were minor differences in the choice of attribute names and a few of there were more structural.

 

I summarized proposals for both changes to the SBOM model and the SPDX model at the beginning of the document.  All proposals are related to making the 2 models compatible in SPDX 3.0.  There are 31 proposed changes to the SBOM and 13 proposed changes to SPDX.  Since it is easier to change an unpublished standard than to create incompatibilities in existing documents and tools, I leaned more toward changes in the SBOM than changes in SPDX.  Please note that these proposals are my own and do not reflect the opinions of the SPDX community as a whole.  It is likely that these changes will require quite a bit of discussion within the SPDX community and may results in changes or counter-proposals.

 

There are a couple of categories of changes I would like to highlight:

  • Attribute names in SPDX tend to be unique so that they can be compatible with W3C/RDF existing and proposed vocabularies.  For example, using fileType rather than type within a File Content class allows the attribute to be easily associated with other uses of the term fileType even outside of SPDX.  This was a strong consideration during the SPDX development. 
  • The external document reference structure is different and I believe structurally incompatible.  I’m not sure I fully understand how the SBOM proposed approach will work with concrete documents.  This is something that should probably be discussed on a call.

 

Best regards,

Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email:

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.