Re: Proposed spec for external packages

Jeremiah Foster <jeremiah.foster@...>

On Wed, Aug 5, 2015 at 4:56 PM, Kate Stewart <kstewart@...> wrote:

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: 

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.

All I can do is comment on the SPDX spec from the perspective of a small business and FOSS contributor. The spec is already quite heavy weight and adding this tag might make sense for the larger commercial organizations, but it doesn't fit the need for a lightweight process that SME's use in my experience.

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.     

I don't see the use case. I already use Debian's security tracking which relies on CVE's and Debian package versions and that works quite well. I personally wouldn't consume this additional tag but I see how it might be used to market commercial tools. 

As an aside, after NIST's work with crypto ciphers I wonder how closely FOSS projects will follow their proposals?  
There is another proposal already in discussion to include external identifiers which include the Debian, Fedora, Maven, etc. repositories. 




Join to automatically receive all group messages.