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

Technical Team/Proposals/2012-06-06/Detached Signed SPDX Files

From SPDX Wiki
< Technical Team‎ | Proposals
Revision as of 17:37, 6 March 2012 by Eaw (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

 

Status

Draft

Issue

Currently there is no way to be sure that an SPDX file has not been modified by a third party after it was produced. See also, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.

Proposal

Modify the spec to state that

  1. Signing Convention: SPDX producers may  cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  
  2. Signature File Naming Convention: The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.
  3. Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  
  4. SPDX consumers may accept or ignore SPDX signature files. 
  5. SPDX producers would have the option of signing SPDX files but would not be required to do so.  

Example

SPDX file
<code>SPDXVersion: SPDX-1.0 DataLicense: PDDL-1.0 Creator: Person: Ed Warnicke </code>
Signed SPDX file
<code>-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo vuAAn2gLkGsGOntkUTERnISOyOoBJxlT =JxE7 -----END PGP SIGNATURE----- </code>
Command sign an SPDX file
<code> $ gpg --armor --output example.spdx.sign --detach-sig example.spdx</code>

Advantages

Detaching the signature in the SPDX file has several advantages.

  1. It allows underlying tools that are used to process the formats into which SPDX is normally encoded (RDF tools, Tag Tools, XML Tools, etc) to continue to function normally. 
  2. It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who *just* wants to focus on processing SPDX data does not need to worry about MIME wrappers.
  3. It follows the convention already being followed by kernel.org, mavencentral, the apache foundation, and most packagers.

Disadvantages

Detaching the signature in the SPDX file could lead to

  1. Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file
  2. Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files.

Responses to Disadvantages

  1. SPDX signature files can be passed along with SPDX data files by simple archiving in a common archive format like .zip, providing all of the benefits of inline signatures, while retaining the advantages of detached signatures.
  2. The SPDX signature file naming and placement conventions in the proposal eliminate concerns about correlation.

Compatibility

This proposal will produce files that are backwards compatible. Specifically a signed filed will be readable by SPDX-1.0 compliant consumers and any tool capable of reading it's underlying encoding format (RDF, XML, Tag). By making the issue of signing orthogonal, we maintain separation of concerns.