https://wiki.spdx.org/index.php?action=history&feed=atom&title=Technical_Team%2FMinutes%2F2020-09-08 2026-05-07T12:20:32Z Revision history for this page on the wiki MediaWiki 1.23.13 https://wiki.spdx.org/index.php?title=Technical_Team/Minutes/2020-09-08&diff=4875&oldid=prev 2020-09-08T18:05:39Z

<p>Created page with &quot;September 8, 2020 == Attendees == * Thomas Steenbergen * Nisha Kumar * Gary O’Neall * David Kemp * William Bartholomew * Jim Hutchison * Steve Winslow Topics: * How do we...&quot;</p> <p><b>New page</b></p><div>September 8, 2020<br /> == Attendees ==<br /> * Thomas Steenbergen <br /> * Nisha Kumar<br /> * Gary O’Neall<br /> * David Kemp<br /> * William Bartholomew<br /> * Jim Hutchison<br /> * Steve Winslow<br /> <br /> Topics:<br /> * How do we best proceed on documenting the different profiles<br /> * Core 3T SBOM comparison<br /> <br /> == Core 3T SBOM comparison ==<br /> * Comparison of Core 3T model to Core SPDX model<br /> * Slides available at https://docs.google.com/presentation/d/1dvGeCAbOUSD5qFQ6mt1WsnBEZvatnonYpKGdAQCIWZg/edit#slide=id.g95424fd354_0_0 (NOTE: presentation starts a slide 8)<br /> * Similar models<br /> * Proposed changes to SPDX<br /> ** Identity – add structured email field, add structured tool information<br /> * Relationship<br /> ** Subclass of element – adds ID<br /> ** add completeness enum<br /> *** Should completeness be put in a separate profile?<br /> *** General consensus on the call 95% of use cases will not use this so should be added as a profile<br /> *** Agreed to defer the decision until Kate is on the call – Kate has been working with NTIA on this<br /> *** David raised the point that completeness is an optional enumeration and may not complicate the model<br /> *** Desire to simplify by reducing the number of field definitions<br /> ** Make the object independent of the 2 items being related<br /> * Package URL more fundamental – mandatory unique identifier<br /> ** Expanded the URL to be and ArtifactURL – superset of PackageURL which can include other types of artifacts including hardware etc.<br /> ** concern about representing non-public package distribution; PURL may not be mature enough for all use cases<br /> *** add to the PURL or ArtifactURL if it is missing<br /> *** Software heritage approach could be another alternative – less human readable<br /> *** Could we use the SPDX reference ID as a package URL<br /> * Additional HASH algorithms<br /> * Suggestion to create examples for various scenarios (e.g. here’s the source repository a binary artifact was built from)<br /> * Suggest that we also have “bad examples”<br /> * Nisha created a mock-up for a container as part of defining the linking profile<br /> ** Describing the relationships between layers, manifests can be complicated<br /> ** Difficulty in representing URL for container metadata<br /> ** Dynamic systems that re-generate the artifacts<br /> ** Proposal that the SBOM travel with the artifacts in the distributed systems<br /> <br /> ==How to document different profiles==<br /> * ran out of time for this topic – moved to next week<br /> <br /> ==Next Week==<br /> * Linkage profile update<br /> * Nisha to present challenges with adapting to the container / container registry work<br /> * How to document different profiles<br /> <br /> [[Category:Technical|Minutes]]</div>

Goneall