Hi Paul, In response to your proposal:
> Well, at the point that someone (or some script) asserts license metadata, I think it may be worth capturing additional metadata, such as > > - the date that the assertion is made For the SBOM case, this is the creation date in the creation information. For original license declarations in the source code, most (but not all) source code uses some form of source control system that captures the date as part of the checkin. We are also capturing other date/time information as part of the build profile (e.g. built date for the package) that can be useful. If there is any additional date/time information we should capture - please let us know. > - who (or which program) is making the assertion, preferably with some indication of their competence/qualifications For the SBOM, this is the creator field - it can be a person, organization or tool. We don't (and in my opinion shouldn't) capture qualification, competencies in the SBOM itself as these things can change over time and they are likely in the area of opinions and the SPDX spec tries to stick to facts. That being said, most organizations maintain a list of organizations and individuals they trust for analysis. For the original code checkin, the source control systems typically capture the information. > - the basis for the assertion (e.g. manual inspection, automated checking, author of the code etc) Checkout the build profile group - they are working on solving similar use cases for the SPDX 3.0 release. Use cases can be found here: https://github.com/spdx/spdx-3-build-profile/blob/main/usecases.md and minutes here: https://github.com/spdx/meetings/tree/main/build I expect the activity in the build group to pick up now that we have the core model nearly completed. Gary > -----Original Message----- > From: [email protected] <[email protected]> On Behalf Of Paul > Sherwood > Sent: Sunday, January 22, 2023 4:12 AM > To: David Kemp <[email protected]> > Cc: [email protected] > Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...) > > Dave, > > sorry for my late reply - comments inline below... > > On 2023-01-15 16:49, David Kemp wrote: > > 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. > > I agree, the potential cases we have are correct, mistaken, maliciously wrong. > Without an SBOM there's the additional case of undefined. > > > As Polyphemus learned, you don't accomplish anything if you can't > > assign names to things. Not producing SBOMs guarantees that you will > > fail. > > Hmmm - I think that's a bit strong. Lots of software has been successful over > decades without SBOMs :-) > > > Arguing that naming perfection is impossible therefore we should do > > nothing is not persuasive. > > I'm not arguing for doing nothing. I've identified an issue and am trying to > figure out > > a) whether others agree that there's a problem > b) what is already being done about it > c) what else could be done > > > 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. > > True > > >> 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. > > Well, at the point that someone (or some script) asserts licence metadata, I > think it may be worth capturing additional metadata, such as > > - the date that the assertion is made > - who (or which program) is making the assertion, preferably with some > indication of their competence/qualifications > - the basis for the assertion (e.g. manual inspection, automated checking, > author of the code etc) > > br > Paul > > > > > 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: > > ------ > > [1] https://lists.spdx.org/g/Spdx-tech/message/4924 > > [2] https://lists.spdx.org/mt/96263894/1160491 > > [3] https://lists.spdx.org/g/Spdx-tech/post > > [4] https://lists.spdx.org/g/Spdx-tech/editsub/1160491 > > [5] https://lists.spdx.org/g/Spdx-tech/unsub > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4935): https://lists.spdx.org/g/Spdx-tech/message/4935 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]] -=-=-=-=-=-=-=-=-=-=-=-
