On Tue, Aug 4, 2015 at 3:18 PM, Jeremiah Foster <
[email protected]> wrote:

>
>
> On Tue, Aug 4, 2015 at 8:09 PM, Kate Stewart <[email protected]
> > wrote:
>
>> On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <
>> [email protected]> 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 http://spdx.org/sites/spdx/files/SPDX-2.0.pdf
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

>
_______________________________________________
Spdx mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx

Reply via email to