|
Hi SPDX friends, I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! The NTIA doc says that a Supplier Name is:
The name of an entity that creates, defines, and identifies
components.
The SPDX spec for "Package Supplier" is similar but not quite the same flavor:
Identify the actual distribution source for the package/directory identified in the SPDX document. This might or might not be different from the originating distribution source for the package. The name of the Package Supplier shall be an organization or recognized author and not a web site. For example, SourceForge is a host website, not a supplier, the supplier for https://sourceforge.net/projects/bridge/ is “The Linux Foundation.”
I feel like since both specs are asking for the responsible entity, there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...
I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?
Thanks,
Tyler
|
|
|
Sebastian Crane
Dear Tyler,
I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).
The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.
Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).
That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)
Hope this helps, and let me know if I've missed anything!
Best wishes,
Sebastian
toggle quoted messageShow quoted text
On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: Hi SPDX friends,
I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!
The NTIA doc says that a Supplier Name is:
The name of an entity that creates, defines, and identifies
components.
The SPDX spec for "Package Supplier" is similar but not quite the same flavor:
Identify the actual distribution source for the package/directory
identified in the SPDX document. This might or might not be different from
the originating distribution source for the package. The name of the
Package Supplier shall be an organization or recognized author and not a
web site. For example, SourceForge is a host website, not a supplier, the
supplier for https://sourceforge.net/projects/bridge/ is “The Linux
Foundation.”
I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...
I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?
Thanks,
Tyler
|
|
|
Thanks Sebastian, one more comment below here -
Dear Tyler,
I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).
The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.
Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).
That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)
Hope this helps, and let me know if I've missed anything!
This is super helpful - one last clarification then regarding the SourceForge example? "Linux Foundation" is assumed to be the entity responsible for the distribution source (SourceForge in this case?) Is that correct?
Best wishes,
Sebastian
On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:
>Hi SPDX friends,
>
>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!
>
>The NTIA doc says that a Supplier Name is:
>
>>
>> The name of an entity that creates, defines, and identifies
>> components.
>>
>
>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:
>
>>
>> Identify the actual distribution source for the package/directory
>> identified in the SPDX document. This might or might not be different from
>> the originating distribution source for the package. The name of the
>> Package Supplier shall be an organization or recognized author and not a
>> web site. For example, SourceForge is a host website, not a supplier, the
>> supplier for https://sourceforge.net/projects/bridge/ is “The Linux
>> Foundation.”
>>
>
>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...
>
>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?
>
>Thanks,
>
>Tyler
>
>
>
>
>
|
|
|
Dick Brooks
Sebastian, That differs from what I see in the NTIA SBOM Framing document: https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf 2.2.3 Supplier Name name or other identifier of the supplier of a component in an SBOM entry Supplier Name should include some capability to handle multiple names or aliases. When the author and supplier are the same, the supplier created an SBOM for their own component. When the author and supplier are different, the author is making claims or assertions about a component for which the author is not the supplier. 
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given Dear Tyler, I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL). The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common. Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance). That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-) Hope this helps, and let me know if I've missed anything! Best wishes, Sebastian On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: >Hi SPDX friends, > >I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! > >The NTIA doc says that a Supplier Name is: > >> >> The name of an entity that creates, defines, and identifies >> components. >> > >The SPDX spec for "Package Supplier" is similar but not quite the same flavor: > >> >> Identify the actual distribution source for the package/directory >> identified in the SPDX document. This might or might not be different >> from the originating distribution source for the package. The name of >> the Package Supplier shall be an organization or recognized author >> and not a web site. For example, SourceForge is a host website, not a >> supplier, the supplier for https://sourceforge.net/projects/bridge/ >> is “The Linux Foundation.” >> > >I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... > >I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? > >Thanks, > >Tyler > > > > >
|
|
|
I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree?
On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks < dick@...> wrote: Sebastian, That differs from what I see in the NTIA SBOM Framing document: https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf 2.2.3 Supplier Name name or other identifier of the supplier of a component in an SBOM entry Supplier Name should include some capability to handle multiple names or aliases. When the author and supplier are the same, the supplier created an SBOM for their own component. When the author and supplier are different, the author is making claims or assertions about a component for which the author is not the supplier. 
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 -----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given Dear Tyler, I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL). The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common. Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance). That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-) Hope this helps, and let me know if I've missed anything! Best wishes, Sebastian On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: >Hi SPDX friends, > >I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! > >The NTIA doc says that a Supplier Name is: > >> >> The name of an entity that creates, defines, and identifies >> components. >> > >The SPDX spec for "Package Supplier" is similar but not quite the same flavor: > >> >> Identify the actual distribution source for the package/directory >> identified in the SPDX document. This might or might not be different >> from the originating distribution source for the package. The name of >> the Package Supplier shall be an organization or recognized author >> and not a web site. For example, SourceForge is a host website, not a >> supplier, the supplier for https://sourceforge.net/projects/bridge/ >> is “The Linux Foundation.” >> > >I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... > >I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? > >Thanks, > >Tyler > > > > >
|
|
|
Dick Brooks
Brandon, IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name. Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name. The Supplier Name is the party that needs to provide SBOM’s. Again, just IMO. Thanks, Dick Brooks  
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: Brandon Lum <lumb@...> Sent: Wednesday, November 2, 2022 10:25 AM To: dick@... Cc: seabass-labrax@...; spdx-tech@... Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote: Sebastian, That differs from what I see in the NTIA SBOM Framing document: https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf 2.2.3 Supplier Name name or other identifier of the supplier of a component in an SBOM entry Supplier Name should include some capability to handle multiple names or aliases. When the author and supplier are the same, the supplier created an SBOM for their own component. When the author and supplier are different, the author is making claims or assertions about a component for which the author is not the supplier. 
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 -----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given Dear Tyler, I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL). The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common. Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance). That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-) Hope this helps, and let me know if I've missed anything! Best wishes, Sebastian On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: >Hi SPDX friends, > >I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! > >The NTIA doc says that a Supplier Name is: > >> >> The name of an entity that creates, defines, and identifies >> components. >> > >The SPDX spec for "Package Supplier" is similar but not quite the same flavor: > >> >> Identify the actual distribution source for the package/directory >> identified in the SPDX document. This might or might not be different >> from the originating distribution source for the package. The name of >> the Package Supplier shall be an organization or recognized author >> and not a web site. For example, SourceForge is a host website, not a >> supplier, the supplier for https://sourceforge.net/projects/bridge/ >> is “The Linux Foundation.” >> > >I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... > >I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? > >Thanks, > >Tyler > > > > >
|
|
|
This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s
build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions.
We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM
and provenance record for the open-source packages we consume I would like to forward that data along.
Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3?
What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the
original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record?
--
Joe Bussell
Windows Engineering System | Tool Benders
🙋♂️ My pronouns are
he/him (why this matters)
🗓️
Book a meeting with me
👍 Inviting
Feedback
⌚ Timezone: (GMT-8) US Pacific
N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working.
From: Spdx-tech@... <Spdx-tech@...>
On Behalf Of Dick Brooks via lists.spdx.org
Sent: Wednesday, November 2, 2022 7:33 AM
To: 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given
Brandon,
IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name.
Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name.
The Supplier Name is the party that needs to provide SBOM’s.
Again, just IMO.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never
trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: dick@...
Tel: +1 978-696-1788
I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree?
toggle quoted messageShow quoted text
On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks < dick@...> wrote:
Sebastian,
That differs from what I see in the NTIA SBOM Framing document:
https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf
2.2.3 Supplier Name
name or other identifier of the supplier of a component in an SBOM entry
Supplier Name should include some capability to handle multiple names or aliases. When the
author and supplier are the same, the supplier created an SBOM for their own component.
When the author and supplier are different, the author is making claims or assertions about a
component for which the author is not the supplier.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email:
dick@...
Tel:
+1 978-696-1788
-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given
Dear Tyler,
I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words,
the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories
of packages available in RHEL).
The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due
to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.
Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright
over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).
That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it
used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)
Hope this helps, and let me know if I've missed anything!
Best wishes,
Sebastian
On 26 October 2022 17:44:27 BST, "rtp via
lists.spdx.org" <rtp=google.com@...> wrote:
>Hi SPDX friends,
>
>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document (
https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't
find it!
>
>The NTIA doc says that a Supplier Name is:
>
>>
>> The name of an entity that creates, defines, and identifies
>> components.
>>
>
>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:
>
>>
>> Identify the actual distribution source for the package/directory
>> identified in the SPDX document. This might or might not be different
>> from the originating distribution source for the package. The name of
>> the Package Supplier shall be an organization or recognized author
>> and not a web site. For example, SourceForge is a host website, not a
>> supplier, the supplier for
https://sourceforge.net/projects/bridge/
>> is “The Linux Foundation.”
>>
>
>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition
of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in
https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...
>
>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?
>
>Thanks,
>
>Tyler
>
>
>
>
>
|
|
|
Dick Brooks
toggle quoted messageShow quoted text
From: Joe Bussell <joe.bussell@...> Sent: Wednesday, November 2, 2022 11:24 AM To: Richard Brooks <dick@...>; 'Brandon Lum' <lumb@...> Cc: seabass-labrax@...; spdx-tech@... Subject: RE: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions. We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM and provenance record for the open-source packages we consume I would like to forward that data along. Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3? What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record? -- Joe Bussell Windows Engineering System | Tool Benders 🙋♂️ My pronouns are he/him (why this matters) 🗓️ Book a meeting with me 👍 Inviting Feedback ⌚ Timezone: (GMT-8) US Pacific N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working. Brandon, IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name. Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name. The Supplier Name is the party that needs to provide SBOM’s. Again, just IMO. Thanks, Dick Brooks  
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote: Sebastian, That differs from what I see in the NTIA SBOM Framing document: https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf 2.2.3 Supplier Name name or other identifier of the supplier of a component in an SBOM entry Supplier Name should include some capability to handle multiple names or aliases. When the author and supplier are the same, the supplier created an SBOM for their own component. When the author and supplier are different, the author is making claims or assertions about a component for which the author is not the supplier. 
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 -----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given Dear Tyler, I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL). The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common. Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance). That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-) Hope this helps, and let me know if I've missed anything! Best wishes, Sebastian On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: >Hi SPDX friends, > >I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! > >The NTIA doc says that a Supplier Name is: > >> >> The name of an entity that creates, defines, and identifies >> components. >> > >The SPDX spec for "Package Supplier" is similar but not quite the same flavor: > >> >> Identify the actual distribution source for the package/directory >> identified in the SPDX document. This might or might not be different >> from the originating distribution source for the package. The name of >> the Package Supplier shall be an organization or recognized author >> and not a web site. For example, SourceForge is a host website, not a >> supplier, the supplier for https://sourceforge.net/projects/bridge/ >> is “The Linux Foundation.” >> > >I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... > >I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? > >Thanks, > >Tyler > > > > >
|
|
|
Dick Brooks
toggle quoted messageShow quoted text
From: Joe Bussell <joe.bussell@...> Sent: Wednesday, November 2, 2022 11:24 AM To: Richard Brooks <dick@...>; 'Brandon Lum' <lumb@...> Cc: seabass-labrax@...; spdx-tech@... Subject: RE: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions. We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM and provenance record for the open-source packages we consume I would like to forward that data along. Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3? What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record? -- Joe Bussell Windows Engineering System | Tool Benders 🙋♂️ My pronouns are he/him (why this matters) 🗓️ Book a meeting with me 👍 Inviting Feedback ⌚ Timezone: (GMT-8) US Pacific N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working. Brandon, IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name. Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name. The Supplier Name is the party that needs to provide SBOM’s. Again, just IMO. Thanks, Dick Brooks  
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote: Sebastian, That differs from what I see in the NTIA SBOM Framing document: https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf 2.2.3 Supplier Name name or other identifier of the supplier of a component in an SBOM entry Supplier Name should include some capability to handle multiple names or aliases. When the author and supplier are the same, the supplier created an SBOM for their own component. When the author and supplier are different, the author is making claims or assertions about a component for which the author is not the supplier. 
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788 -----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given Dear Tyler, I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL). The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common. Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance). That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-) Hope this helps, and let me know if I've missed anything! Best wishes, Sebastian On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote: >Hi SPDX friends, > >I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it! > >The NTIA doc says that a Supplier Name is: > >> >> The name of an entity that creates, defines, and identifies >> components. >> > >The SPDX spec for "Package Supplier" is similar but not quite the same flavor: > >> >> Identify the actual distribution source for the package/directory >> identified in the SPDX document. This might or might not be different >> from the originating distribution source for the package. The name of >> the Package Supplier shall be an organization or recognized author >> and not a web site. For example, SourceForge is a host website, not a >> supplier, the supplier for https://sourceforge.net/projects/bridge/ >> is “The Linux Foundation.” >> > >I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... > >I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? > >Thanks, > >Tyler > > > > >
|
|
|
