THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Technical Team/Proposals/Rough proposal for provenance, hierarchy and aggregation, and supply chain friendliness in SPDX 2.0"

From SPDX Wiki
Jump to: navigation, search
Line 1: Line 1:
−
<p>A desire has been expressed to be able to have SPDX be capable of expressing</p><p>&nbsp;</p><ol><li>Hiearchy ( package A contains packages B, C, etc)</li><li>Authentication ( we can know precisely who said what and when about a package)</li><li>How software flows through a supply chain (upstream to packager, through several intermediate vendors to consumer)</li></ol><p>A rough example of this thought is shown in the diagram below, showing how the coreutils package might be represented:</p><p>&nbsp;<img src="http://spdx.org/system/files/spdxdoodle_0.jpg" alt="" width="586" height="372" /></p><p>&nbsp;The simple story behind this diagram is this:</p><ol><li>The upstream maintainer of coreutils provides an SPDX file which</li><ol><li>Provides information for the copyrighted entity that is the package as a whole</li><li>Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)</li><li>Provides a coreutils.spdx.sig file with the signature for the coreutils.spdx file (so we can authenticate it)</li></ol><li>This coreutils.spdx file is in the coreutils.tar.gz for the upstream</li><li>The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:</li><ol><li>Provides information for the copyrighted entity that is the rpm (or deb) package as a whole</li><li>Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package</li><li>For the coreutils.tar.gz file (also contained in the rpm or deb package), provides it's SPDX information by *referencing* the coreutils.spdx in the coreutils.tar.gz file.</li><li>Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.</li></ol></ol><p>&nbsp;</p><p>Diagram for a Concrete proposal (very very rough) for structure (note, notes that say 'Concrete' or 'Referential' are just indicating an 'or' in the doc structure):</p><p>&nbsp;</p><p><img src="http://spdx.org/system/files/spdxdoodle2.jpg" alt="" /></p><p>&nbsp;</p>
+
<p>A desire has been expressed to be able to have SPDX be capable of expressing</p><p>&nbsp;</p><ol><li>Hiearchy ( package A contains packages B, C, etc)</li><li>Authentication ( we can know precisely who said what and when about a package)</li><li>How software flows through a supply chain (upstream to packager, through several intermediate vendors to consumer)</li></ol><p>A rough example of this thought is shown in the diagram below, showing how the coreutils package might be represented:</p><p>&nbsp;<img src="http://spdx.org/system/files/spdxdoodle_0.jpg" alt="" width="586" height="372" /></p><p>&nbsp;The simple story behind this diagram is this:</p><ol><li>The upstream maintainer of coreutils provides an SPDX file which</li><ol><li>Provides information for the copyrighted entity that is the package as a whole</li><li>Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)</li><li>Provides a coreutils.spdx.sig file with the signature for the coreutils.spdx file (so we can authenticate it)</li></ol><li>This coreutils.spdx file is in the coreutils.tar.gz for the upstream</li><li>The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:</li><ol><li>Provides information for the copyrighted entity that is the rpm (or deb) package as a whole</li><li>Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package</li><li>For the coreutils.tar.gz file (also contained in the rpm or deb package), provides it's SPDX information by *referencing* the coreutils.spdx in the coreutils.tar.gz file.</li><li>Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.</li></ol></ol><p>&nbsp;</p><p>Diagram for a Concrete proposal (very very rough) for structure (note, notes that say 'Concrete' or 'Referential' are just indicating an 'or' in the doc structure):</p><p>&nbsp;</p><p><img src="http://spdx.org/system/files/spdxdoodle2.jpg" alt="" /></p><p>Description of diagram</p><ul><li><strong>Top:</strong> Simple top level place to start</li><ul><li><strong>SPDXFile</strong>: File containing SPDX data</li><ul><li><strong>SPDXElement:</strong> The containing element for SPDX data for a given copyrightable work. &nbsp;It's SPDXElements all the way down.</li><ul><li></li></ul></ul><li><strong>SPDXFileSig</strong>: Separate file containing the signature for the octets of the SPDXFile&nbsp;</li></ul></ul>

Revision as of 22:32, 5 December 2011

A desire has been expressed to be able to have SPDX be capable of expressing

 

  1. Hiearchy ( package A contains packages B, C, etc)
  2. Authentication ( we can know precisely who said what and when about a package)
  3. How software flows through a supply chain (upstream to packager, through several intermediate vendors to consumer)

A rough example of this thought is shown in the diagram below, showing how the coreutils package might be represented:

 <img src="http://spdx.org/system/files/spdxdoodle_0.jpg" alt="" width="586" height="372" />

 The simple story behind this diagram is this:

  1. The upstream maintainer of coreutils provides an SPDX file which
    1. Provides information for the copyrighted entity that is the package as a whole
    2. Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)
    3. Provides a coreutils.spdx.sig file with the signature for the coreutils.spdx file (so we can authenticate it)
  2. This coreutils.spdx file is in the coreutils.tar.gz for the upstream
  3. The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:
    1. Provides information for the copyrighted entity that is the rpm (or deb) package as a whole
    2. Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package
    3. For the coreutils.tar.gz file (also contained in the rpm or deb package), provides it's SPDX information by *referencing* the coreutils.spdx in the coreutils.tar.gz file.
    4. Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.

 

Diagram for a Concrete proposal (very very rough) for structure (note, notes that say 'Concrete' or 'Referential' are just indicating an 'or' in the doc structure):

 

<img src="http://spdx.org/system/files/spdxdoodle2.jpg" alt="" />

Description of diagram

  • Top: Simple top level place to start
    • SPDXFile: File containing SPDX data
      • SPDXElement: The containing element for SPDX data for a given copyrightable work.  It's SPDXElements all the way down.
    • SPDXFileSig: Separate file containing the signature for the octets of the SPDXFile 
Retrieved from "https://wiki.spdx.org/index.php?title=Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0&oldid=1241"