1. posterid:548471
  2. Proposed spec for external packages

Re: Proposed spec for external packages

Kate Stewart
 



On Tue, Aug 4, 2015 at 3:18 PM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Tue, Aug 4, 2015 at 8:09 PM, Kate Stewart <kstewart@...> wrote:
On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted,`

How do you propose it be trusted? It is just a string! You need substantially more infrastructure than just a SPDX tag to generate trust. 

There is no SPDX tag - per se.   An SPDX document for a package contains hash codes at the file level.  (SHA1, SHA256 ),  as well as an algorithm for a verification code to be generated from the component files at the package level. 

in  Section 3 Package Section see 3.8 Package Verification Code & 3.9 Package Checksum.
in  Section 4 File Section see 4.4 File Checksum.

The proposal is to add cross link to other databases where security information is being tracked already.

Today this is primarily through the CPE,  however NIST is reviewing SWID proposal to be used, and so linking to the software identifier tag (SWID tag),  seems to be useful from a security vulnerability tracking perspective.   ie. lets not duplicate work, but rather make other's work easy to find.     

There is another proposal already in discussion to include external identifiers which include the Debian, Fedora, Maven, etc. repositories. 

Kate
Join {spdx@lists.spdx.org to automatically receive all group messages.