THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Technical Team/Proposals/2012-06-06/Detached Signed SPDX Files"
From SPDX Wiki
< Technical Team | Proposals
(Convert to MediaWiki syntax) |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | 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, [https://bugs.linuxfoundation.org/show_bug.cgi?id=980 issue 980]. | ||
+ | |||
+ | ==Proposal== | ||
+ | |||
+ | Modify the spec to state that | ||
+ | |||
+ | # '''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. | ||
+ | # '''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. | ||
+ | # '''Signature File Renaming: '''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. | ||
+ | # '''Consumption Optional: '''SPDX consumers '''may''' accept or ignore SPDX signature files. | ||
+ | # '''Production Optional: '''SPDX producers would have the option of signing SPDX files but would '''not''' be required to do so. | ||
+ | |||
+ | ==Example== | ||
+ | |||
+ | ===SPDX file=== | ||
+ | |||
+ | SPDXVersion: SPDX-1.0 | ||
+ | DataLicense: PDDL-1.0 | ||
+ | Creator: Person: Ed Warnicke | ||
+ | |||
+ | ===Signed SPDX file=== | ||
+ | |||
+ | |||
+ | -----BEGIN PGP SIGNATURE----- | ||
+ | Version: GnuPG/MacGPG2 v2.0.17 (Darwin) | ||
+ | Comment: GPGTools - http://gpgtools.org | ||
+ | iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo | ||
+ | vuAAn2gLkGsGOntkUTERnISOyOoBJxlT | ||
+ | =JxE7 | ||
+ | -----END PGP SIGNATURE ----- | ||
+ | |||
+ | ===Command sign an SPDX file=== | ||
+ | |||
+ | $ gpg --armor --output example.spdx.sign --detach-sig example.spdx | ||
+ | |||
+ | ==Advantages== | ||
+ | |||
+ | Detaching the signature in the SPDX file has several advantages. | ||
+ | |||
+ | # '''Leverage Existing Tools: '''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. | ||
+ | # '''Tooling Simplication: '''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 knowing how to unpack a wrapper. | ||
+ | # '''Community Standard: '''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 | ||
+ | |||
+ | # '''Misplaced Signatures: '''Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file | ||
+ | # '''Signature Correlation: '''Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files. | ||
+ | |||
+ | <div> | ||
+ | |||
+ | ==Responses to Disadvantages== | ||
+ | |||
+ | # '''Misplaced Signatures -- Existing Archive Formats: '''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. This solution is proposed in [[Technical_Team/Proposals/2012-Mar-11_SPDX_File_Aggregation]] | ||
+ | # '''Signature Correlation - Signature File Naming Convention: '''The SPDX signature file naming and placement conventions in the proposal eliminate concerns about correlation. | ||
+ | |||
+ | </div> | ||
+ | |||
+ | ==Compatibility== | ||
+ | |||
+ | This proposal will produce files that are trivially 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. | ||
+ | |||
+ | [[Category:Technical]] |
Latest revision as of 11:30, 7 March 2013
Status: draft
Contents
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, issue 980.
Proposal
Modify the spec to state that
- 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.
- 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.
- Signature File Renaming: 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.
- Consumption Optional: SPDX consumers may accept or ignore SPDX signature files.
- Production Optional: SPDX producers would have the option of signing SPDX files but would not be required to do so.
Example
SPDX file
SPDXVersion: SPDX-1.0 DataLicense: PDDL-1.0 Creator: Person: Ed Warnicke
Signed SPDX file
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo vuAAn2gLkGsGOntkUTERnISOyOoBJxlT =JxE7 -----END PGP SIGNATURE -----
Command sign an SPDX file
$ gpg --armor --output example.spdx.sign --detach-sig example.spdx
Advantages
Detaching the signature in the SPDX file has several advantages.
- Leverage Existing Tools: 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.
- Tooling Simplication: 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 knowing how to unpack a wrapper.
- Community Standard: 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
- Misplaced Signatures: Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file
- Signature Correlation: Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files.
Responses to Disadvantages
- Misplaced Signatures -- Existing Archive Formats: 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. This solution is proposed in Technical_Team/Proposals/2012-Mar-11_SPDX_File_Aggregation
- Signature Correlation - Signature File Naming Convention: The SPDX signature file naming and placement conventions in the proposal eliminate concerns about correlation.
Compatibility
This proposal will produce files that are trivially 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.