Assigning a License ID to some amorphous "thing" called a package -- that can be composed of a web of components created at different times by different authors, and processed by multiple builders at multiple points in a build hierarchy -- is tricky. The lower down in that hierarchy the easier it is to track - if at the bottom a developer of a leaf (dependency-less) component includes the text of the MIT license in his component, his intent is pretty clear. At that point an SBOM creator binding a license ID to a package ID can be 1) correct, 2) mistaken, or 3) malicious. As packages are combined up the dependency tree things only get more complicated, but the correctness possibilities are the same.
As Polyphemus learned, you don't accomplish anything if you can't assign names to things. Not producing SBOMs guarantees that you will fail. Arguing that naming perfection is impossible therefore we should do nothing is not persuasive. As technology gets adopted ISO 9000 quality assurance processes and certifications may follow, and pushing to develop QA standards is great.. Until then, caveat emptor. Consumers will have to make judgement calls about provider reliability like they do everywhere else in life. So the underlying problem I see is that manually created metadata can be > misleading and lead to false confidence (as demonstrated by the keyring > example). What mechanisms can be applied to ensure that license > assertions based on SPDX metadata are actually true? What is your proposal? Forbid manually-created metadata? Forbid use of SBOMs entirely? I don't believe that's the straightest path to QA. Just an opinion, Dave On Sun, Jan 15, 2023 at 9:10 AM Dick Brooks < [email protected]> wrote: > Thanks for your feedback, Paul. > > Regarding: > " With regard to licencing, the base premise that a human asserts licence > in > metadata, without qualification, seems risky to me. Is there any > traceability for who makes the assertion in the first place, and on what > basis? And when the software changes, is there any way to force > reassessment > (or at least reassertion) by someone competent?" > > Each supplier decides for themselves the terms and conditions upon which a > party may use their software, which is expressed in a license. There is no > right or wrong or anyone to verify that the party issuing the license is > valid. A user of the software decides to accept the terms and conditions in > the license, or not. No validation required, the license contains the terms > and conditions as determined by the party issuing the license. > > 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! T > http://www.reliableenergyanalytics.com > Email: [email protected] > Tel: +1 978-696-1788 > > -----Original Message----- > From: Paul Sherwood <[email protected]> > Sent: Sunday, January 15, 2023 3:47 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...) > > Hi Dick > > thank you for your comments. Please see my thoughts inline > > On 2023-01-14 13:12, Dick Brooks wrote: > > There is no escaping manual input from the process that leads to an > > SBOM, SPDX or CycloneDX. Someone has to input the data somewhere in > > order for it to be available at SBOM creation time. > > True, but my interest relates to > > - repeatable construction of evolving software at scale (where automation > provides significant benefits) > - safety-critical and security-critical systems > > Broadly this leads me towards solutions where, once the manual input has > occurred, we can aim to enforce rules and/or automation to mitigate against > errors being introduced. > > > If you are concerned that manual entry occurs somewhere in the > > process that ultimately results in an SBOM then I don't think this > > concern will ever go away. > > > > Manual effort is an inherent part of software creation, and yes, human > > error can, and does occasionally occur. > > You're correct - I expect to remain concerned about human errors, at least > until the AI community comes up with tools to generate the software without > human intervention, at which point we'll have no clue about whether the > metadata is truthful or not :-) > > However, for the versioning example I mentioned, we have techniques that > mitigate very effectively against the problem. A common approach is for > software versioning to be heavily controlled or even generated by tooling. > For example, if we use git, we can ensure that only one version of software > has a given tag. > > With regard to licencing, the base premise that a human asserts licence in > metadata, without qualification, seems risky to me. Is there any > traceability for who makes the assertion in the first place, and on what > basis? And when the software changes, is there any way to force > reassessment > (or at least reassertion) by someone competent? > > br > Paul > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4924): https://lists.spdx.org/g/Spdx-tech/message/4924 Mute This Topic: https://lists.spdx.org/mt/96263894/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
