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
<d...@reliableenergyanalytics.com> 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: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788
-----Original Message-----
From: Paul Sherwood <paul.sherw...@codethink.co.uk>
Sent: Sunday, January 15, 2023 3:47 AM
To: d...@reliableenergyanalytics.com
Cc: spdx-tech@lists.spdx.org
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 (#4933): https://lists.spdx.org/g/Spdx-tech/message/4933
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
