16 Aug
2022
16 Aug
'22
4:42 a.m.
Hi!
SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s
a new working group in the IETF working on it and several other standardization bodies.
A starting point is identification of the license in each source code file with a
parseable SPDX identifier.
- Is anyone against adding that to our source code?
- Would it be beneficial for packaging in any way?
I think at some point in the future, a SBOM list in <pick format> will be included
in packages, in order to be able to produce a SBOM for the container or the machine.
As we have multiple licenses in the source code it’s important to mark every file
correctly.
I can start experimenting with http_client, then work myself around, if the dev community
doesn’t scream and argue that it’s a bad thing (TM).
Read more here
- SPDX - a linux foundation project ans ISO standard - https://spdx.dev
- Tags in source code - https://spdx.dev/ids/
Cheers,
/O
16 Aug
16 Aug
8:53 a.m.
Hello,
I have nothing against it, just it should be done for the whole project (i.e., all files)
in the repository if somebody decides to do it.
Otherwise, we will end up with partial information, which might be misleading to some
people rely on the identifier.
I know a bit about the SPDX standard, it sounds reasonable for me and its only one line
added per file, so not much overhead.
Cheers,
Henning
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Tuesday, August 16, 2022 10:43 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] SPDX identifiers in source code
Hi!
SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s
a new working group in the IETF working on it and several other standardization bodies.
A starting point is identification of the license in each source code file with a
parseable SPDX identifier.
- Is anyone against adding that to our source code?
- Would it be beneficial for packaging in any way?
I think at some point in the future, a SBOM list in <pick format> will be included
in packages, in order to be able to produce a SBOM for the container or the machine.
As we have multiple licenses in the source code it’s important to mark every file
correctly.
I can start experimenting with http_client, then work myself around, if the dev community
doesn’t scream and argue that it’s a bad thing (TM).
Read more here
- SPDX - a linux foundation project ans ISO standard - https://spdx.dev
- Tags in source code - https://spdx.dev/ids/
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
9:43 a.m.
On 16 Aug 2022, at 14:53, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
I have nothing against it, just it should be done for the whole project (i.e., all files)
in the repository if somebody decides to do it.
Otherwise, we will end up with partial information, which might be misleading to some
people rely on the identifier.
Absolutely. It will affect all files but we don’t
have to mark them all overnight, but can do it in a period between releases.
I know a bit about the SPDX standard, it sounds reasonable for me and its only one line
added per file, so not much overhead.
Great. Are you aware of any good tools that
parse and produce some interesting output?
Thank you for the feedback.
/O
Cheers,
Henning
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Tuesday, August 16, 2022 10:43 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] SPDX identifiers in source code
Hi!
SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s
a new working group in the IETF working on it and several other standardization bodies.
A starting point is identification of the license in each source code file with a
parseable SPDX identifier.
- Is anyone against adding that to our source code?
- Would it be beneficial for packaging in any way?
I think at some point in the future, a SBOM list in <pick format> will be included
in packages, in order to be able to produce a SBOM for the container or the machine.
As we have multiple licenses in the source code it’s important to mark every file
correctly.
I can start experimenting with http_client, then work myself around, if the dev community
doesn’t scream and argue that it’s a bad thing (TM).
Read more here
- SPDX - a linux foundation project ans ISO standard - https://spdx.dev
- Tags in source code - https://spdx.dev/ids/
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
17 Aug
17 Aug
5:15 a.m.
Hello Olle,
yes, it should be finalized in a shorter period and not going into multiple release
cycles.
If we have done it, it should be also probably added to the contribution guidelines e.g.,
for new modules.
Not sure what kind of tools you are referring to. For the addition to the source code,
this could be probably done with some scripting and sed or similar tools.
I looked again to the SPDX standard. This is actually quite extensive and there are many
fields that could be added.
Example:
https://github.com/spdx/spdx-spec/blob/development/v2.2.2/examples/SPDXTagE…
Additionally, it can be added as tags (as above), XML, JSON etc..
This has grown quite a lot since I have last investigated it.
You were not proposing to add multiple tags to the source code files, right? If yes, this
should be discussed in a larger round, maybe in some online developer meeting or
similar.
It would be difficult to maintain, if we compare e.g., to the Doxygen topic which was done
for many modules, but not all parts of the code.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-----Original Message-----
From: Olle E. Johansson <oej(a)edvina.net>
Sent: Tuesday, August 16, 2022 3:44 PM
To: Henning Westerholt <hw(a)gilawa.com>
Cc: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: Re: [sr-dev] SPDX identifiers in source code
On 16 Aug 2022, at 14:53, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
I have nothing against it, just it should be done for the whole project (i.e., all files)
in the repository if somebody decides to do it.
Otherwise, we will end up with partial information, which might be misleading to some
people rely on the identifier.
Absolutely. It will affect all files but we don’t have to mark them all overnight,
but can do it in a period between releases.
I know a bit about the SPDX standard, it sounds reasonable for me and its only one line
added per file, so not much overhead.
Great. Are you aware of any good tools that parse and produce some interesting
output?
Thank you for the feedback.
/O
Cheers,
Henning
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Tuesday, August 16, 2022 10:43 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] SPDX identifiers in source code
Hi!
SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s
a new working group in the IETF working on it and several other standardization bodies.
A starting point is identification of the license in each source code file with a
parseable SPDX identifier.
- Is anyone against adding that to our source code?
- Would it be beneficial for packaging in any way?
I think at some point in the future, a SBOM list in <pick format> will be included
in packages, in order to be able to produce a SBOM for the container or the machine.
As we have multiple licenses in the source code it’s important to mark every file
correctly.
I can start experimenting with http_client, then work myself around, if the dev community
doesn’t scream and argue that it’s a bad thing (TM).
Read more here
- SPDX - a linux foundation project ans ISO standard - https://spdx.dev
- Tags in source code - https://spdx.dev/ids/
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
5:39 a.m.
On 17 Aug 2022, at 11:15, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello Olle,
yes, it should be finalized in a shorter period and not going into multiple release
cycles.
If we have done it, it should be also probably added to the contribution guidelines e.g.,
for new modules.
Right
Not sure what kind of tools you are referring to. For the addition to the source code,
this could be probably done with some scripting and sed or similar tools.
Tools that
generate an overview of the product. I’ll read on here. But tagging source is a starting
point.
I looked again to the SPDX standard. This is actually quite extensive and there are many
fields that could be added.
Example:
https://github.com/spdx/spdx-spec/blob/development/v2.2.2/examples/SPDXTagE…
I think that’s the generated product, the SBOM, not what you add to the source code.
The tag from the source is
here:
LicenseInfoInFile: GPL-2.0-only
(row 49 in that document)
Additionally, it can be added as tags (as above), XML, JSON etc..
This has grown quite a lot since I have last investigated it.
You were not proposing to add multiple tags to the source code files, right? If yes, this
should be discussed in a larger round, maybe in some online developer meeting or similar.
It would be difficult to maintain, if we compare e.g., to the Doxygen topic which was
done for many modules, but not all parts of the code.
No, I was just proposing to
add a single tag alongside the license text.
There are tools for scanning files and creating base info for debian packages, if I
understand it right. At some point, I suspect it will happen.
We have an issue there with files under different licenses, but a combined license for the
running software, but that is another issue to handle when that problem comes up.
/O
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-----Original Message-----
From: Olle E. Johansson <oej(a)edvina.net>
Sent: Tuesday, August 16, 2022 3:44 PM
To: Henning Westerholt <hw(a)gilawa.com>
Cc: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: Re: [sr-dev] SPDX identifiers in source code
On 16 Aug 2022, at 14:53, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
I have nothing against it, just it should be done for the whole project (i.e., all files)
in the repository if somebody decides to do it.
Otherwise, we will end up with partial information, which might be misleading to some
people rely on the identifier.
Absolutely. It will affect all files but we don’t
have to mark them all overnight, but can do it in a period between releases.
I know a bit about the SPDX standard, it sounds reasonable for me and its only one line
added per file, so not much overhead.
Great. Are you aware of any good tools that
parse and produce some interesting output?
Thank you for the feedback.
/O
Cheers,
Henning
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Tuesday, August 16, 2022 10:43 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] SPDX identifiers in source code
Hi!
SBOM - Software Bill of Materials - often comes up in discussions in my projects. There’s
a new working group in the IETF working on it and several other standardization bodies.
A starting point is identification of the license in each source code file with a
parseable SPDX identifier.
- Is anyone against adding that to our source code?
- Would it be beneficial for packaging in any way?
I think at some point in the future, a SBOM list in <pick format> will be included
in packages, in order to be able to produce a SBOM for the container or the machine.
As we have multiple licenses in the source code it’s important to mark every file
correctly.
I can start experimenting with http_client, then work myself around, if the dev community
doesn’t scream and argue that it’s a bad thing (TM).
Read more here
- SPDX - a linux foundation project ans ISO standard - https://spdx.dev
- Tags in source code - https://spdx.dev/ids/
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
870
days inactive
871
days old
4 comments
2 participants
participants (2)
-
Henning Westerholt -
Olle E. Johansson