-
-
Notifications
You must be signed in to change notification settings - Fork 93
What is the recommended way to distinguish between supplier and publisher? #648
- What is the recommended way to distinguish between supplier and publisher?
In many package ecosystems (e.g., Debian, RPM, Maven), the metadata might only indicate a maintainer or packager.
For example, if Red Hat repackages curl, is Red Hat the supplier, the publisher, or both?
All reactions
-
👍 2 -
👀 1
Replies: 2 comments 7 replies
This is a great question, and one of a number of questions where guidance is not perhaps clear.
I look forward to other's opinions here - but here is my take (based on CycloneDX 1.6) and using OpenSSL as an example:
- Supplier - Where you got the Component from - could be RedHat as they are where you get the RPM from if you're a RedHat customer
- Manufacturer - Who created the Component - likely RedHat as they created the RPM
- Publisher - Who published the Component - would be RedHat if they are publishing the RPM
- Authors - The person(s) who created the Component - probably also RedHat in this case
The key here is that the Component is the OpenSSL RPM provided and created by RedHat.
If the Component was OpenSSL Source .tar.gz, we'd have different values.
Happy for folks to provide their opinion and see where there is and is not alignment!
All reactions
-
👍 1
No disagreements with the above, other than perhaps with authors. In this example, I would not expect RedHat to be in the list of authors. I would expect the names of all major contributors to the project, including the maintainers.
There's also an external reference of type vcs which would allow you to retrieve every contributor to the project.
Note: These definitions align with NIST and all other references for both physical and digital supply chains, but they do not align with the NTIA minimum elements. In that guidance, there is no distinction between supplier and manufacturer. They are the same.
All reactions
But I would also expect the pedigree to be completed so that it is clear that the upstream component was from the OpenSSL project which has a different supplier, manufacturer, publisher, and authors than the RedHat fork (an ancestor in CycloneDX).
All reactions
-
👍 1 -
🎉 3
Pedigree is the missing link here!
All reactions
-
👍 1
I would expect the names of all major contributors to the project, including the maintainers.
Does it mean OpenSSL maintainers?
Supplier - Where you got the Component from - could be RedHat as they are where you get the RPM from if you're a RedHat customer
For example, when an npm package is installed, does that mean the supplier would be the npm registry?
All reactions
I share a similar doubt: what is the difference between Supplier and Publisher? According to the spec the Supplier can modify (repackage for example) the artifact, while the publisher can not.
All reactions
I think using a Redhat "forked" package is propably not the best example unless we add a few more. With PyPi I can contribute - "create" the package myself and PyPi distributes it. How would that look? What about Maven?
All reactions
-
👍 1