Generate SBOM files for each ports

[mat]

Summary

This is based on D56474, it only generates the basic .pc files.

As depends get updated, if we generated the other two files statically, they would soon become outdated and contain invalid information. So the .spdx and .jsonld files need to be generated either by a pkg hook, or a separate tool. (see https://reviews.freebsd.org/D56474#1375885 a more complete explanation)

[khorben]

Besides my comment above, I wonder if we want to apply a different namespace to the SBOM files generated for base (in D56474 and D60352), or if it should be up to the user to set the correct PKG_CONFIG_LIBDIR. With pkgbase coming, we may want to be able to express dependencies on components from the base system anyway.
Should I change the naming in the base system?
Should we align names between ports and the base system? I can picture cases like expat/libexpat/libbsdxml, curl/libcurl, openssl{36,41,42} etc to be tricky.

Mk/Scripts/create-sbom.sh

53

I am testing with e.g., devel/git and notice that its license is set to GPLv2. While bomtool(1) from pkgconf does not seem to care, the SPDX standard expects license names from its SPDX License List. ISTM that CycloneDX also uses SPDX License IDs by the way.
This is probably not a blocker for this change, as it is a different issue really, but should we switch ports to the SPDX ID for the license field?
Or on the contrary or in the meantime, should we perform the conversion in e.g., the create-sbom.sh script here?

[mat]

In D60441#1387459, @khorben wrote:

Besides my comment above, I wonder if we want to apply a different namespace to the SBOM files generated for base (in D56474 and D60352), or if it should be up to the user to set the correct PKG_CONFIG_LIBDIR. With pkgbase coming, we may want to be able to express dependencies on components from the base system anyway.
Should I change the naming in the base system?
Should we align names between ports and the base system? I can picture cases like expat/libexpat/libbsdxml, curl/libcurl, openssl{36,41,42} etc to be tricky.

That is a good point. I don't quite know.
I wonder if the base system sboms should be prefixed with FreeBSD- like the base system packages.
Like, when a user has OPENSSL_DEFAULT=base, and a port has USES=ssl, then it'd get a dependency on "FreeBSD-openssl", and if the user has OPENSSL_DEFAULT=openssl, the port would get the dep on "openssl" which would be the ports one.

I am not sure this is needed though.
From what I understand, the idea from having an sbom is you collect all the .spdx/.jsonld files you have, from the base system and the ports, and this gives you the SBOM from the whole system.
The idea is that in the end, you get a very large list of software that are installed on the system, you probably do not have an absolute need to have a link from ports nginx to base openssl.

Mk/Scripts/create-sbom.sh

53

@bofh is working on converting our license framework to SPDX, so I left this out of the scope of this change, working on the assumption that what I get from the framework will be correct when this lands and starts being useful.