28 Sep
2023
28 Sep
'23
8:17 p.m.
On 28.09.23 13:13, Olle E. Johansson via sr-users wrote:
Maybe leveraging ldd in a first phase can help building the chain of
dependencies:
$ ldd src/kamailio
linux-vdso.so.1 (0x0000ffff91745000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff90f30000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff90d80000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff9170c000)
$ ldd src/modules/tls/tls.so
linux-vdso.so.1 (0x0000ffff96e5d000)
libssl.so.3 => /lib/aarch64-linux-gnu/libssl.so.3 (0x0000ffff96ca0000)
libcrypto.so.3 => /lib/aarch64-linux-gnu/libcrypto.so.3
(0x0000ffff968b0000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff96700000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff96e24000)
$ ldd /lib/aarch64-linux-gnu/libcrypto.so.3
linux-vdso.so.1 (0x0000ffff9952c000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff98f50000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff994f3000)
Might take some time, a matter of what modules are used, but if really
needed, the process should be doable manually.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com
On 28 Sep 2023, at 12:36, Ivan Ribakov via
sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi Olle,
Yes, I realised by now that taking enabled Kamailio modules into
account when generating SBOM is too much to ask. I'd be ok with
obtaining full list of Kamailio dependencies (with transitive
dependencies if possible) and then manually filtering them based on
module usage. Not sure if at any point during Kamailio build process
all sources + dependency sources/binaries are present in the system
for scanning/identification?
I'm mainly interested in listing (and validating licenses) and having
a general inventory. Any recommendations?
I did try a beta of a tool in cyclonedx toolset for scanning C files
and it crashed. Will try again, but so far I haven’t succeeded.
I suggest we would need one SBOM based on a linux distro, like Debian
and one
more generic based on C code and the versions of libraries we
recommend. I have tried to add pointers to the various
third party dependencies in the READMEs over the years in a somewhat
unstructured effort, but the information is there.
Maybe we can add the dependencies in a way that’s parseable in order
to build an SBOM.
C code doesn’t have package management like Python, Perl, Go and
others so it’s tricky to automate creation of SBOMs.
I think that the SBOM tree for the source code and dependencies would
grow quite large.
Anyway - at this time, I failed. :-)