[yocto] OpenLDAP License Update?
Hello, we noticed that the OpenLDAP recipe provided in meta-oe/recipes-support/openldap does not use an SPDX identifier for the license but rather just "OpenLDAP" [1]. Based on the comment above the custom license was introduced, because an official license did not exist on OpenSource.org. But in the meantime, the license was added to OpenSource.org and provides a correct SPDX identifier [2]. So, I was wondering if the license can be changed to "OLDAP-2.8" or if there are any other reasons for keeping the old "OpenLDAP" license for the recipe? Kindest regards, Fabian Hanke [1] https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/openldap/openldap_2.6.7.bb#n9 [2] https://opensource.org/license/oldap-2-8 Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63364): https://lists.yoctoproject.org/g/yocto/message/63364 Mute This Topic: https://lists.yoctoproject.org/mt/106761034/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] GPL License Compliance - Automatically detect linking against GPL libraries
Hello, thank you for all the responses so far. I guess we will have a look at fossology and fossas, but we would prefer a solution which does not require an additional thirdparty service. We know that there are different types of GPL licenses which bring different obligations. We are searching for an automatic mechanism to detect linking to a shared library from a GPL package. We thought there might be a way to utilize the build system’s shared library resolver which is used for the automatic runtime added runtime dependencies [1]. For static libraries we found that they are disabled by default [2]. [1] https://docs.yoctoproject.org/overview-manual/concepts.html#automatically-added-runtime-dependencies [2] https://docs.yoctoproject.org/dev/dev-manual/licenses.html#compliance-limitations-with-executables-built-from-static-libraries Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63247): https://lists.yoctoproject.org/g/yocto/message/63247 Mute This Topic: https://lists.yoctoproject.org/mt/106365537/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] GPL License Compliance - Automatically detect linking against GPL libraries
Hello, we were wondering if anyone has experiences / best practices on how to detect if packages link to a library from another GPL licensed package? We know that there are ways to completely filter out some licenses via INCOMPATIBLE_LICENSE. But from our (limited) legal knowledge it is okay to include them in our image, if we fulfill all the obligations. One obligation implies that code linked to a GPL library will need to have the same license (derivative work). Hence we would like to avoid that packages containing our own closed source software link by accident to a GPL based library. Has anyone experiences / best practices on how to detect this automatically during the bitbake build? Best regards, Fabian Hanke Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63222): https://lists.yoctoproject.org/g/yocto/message/63222 Mute This Topic: https://lists.yoctoproject.org/mt/106365537/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
Hello and thank you for the feedback so far, > The cve-check tooling can check which issues are present and which are fixed > in some way so that information is there. I guess our security department wants a standardized format for all product teams and not use individual tooling for each team (which can be very diverse in a big corp). They would like to quickly be able to answer which products are affected in case of another "log4j incident". It's not about reporting, but rather having a standardized format which can be processed automatically to deal with the ever increasing number of CVEs. > AFAIK, and I'd be happy to be proven wrong, SPDX and SBOM don't help matching > SW component names and version strings so that comparison against CVE > database information works. Only license names are standardized. That is a good point. It also depends on the build configuration whether a component is affected or not. I brought this up as a concern to the security department. > Our experts have also opted for CycloneDX. Is your CycloneDX generator > publicly available? We are still implementing it internally, but started by adapting the following: https://github.com/bgnetworks/meta-dependencytrack > Much more reasonable is to provide a static SBOM which provides > information about: > - Installed packages and versions > - CVE related patches for the packages > - Additional information from CVE_STATUS_* variables (These use cases > were also the motivation for adding this additional information) I also looked into this. The cycloneDX format supports pedigree information for each component, which can be used to add patch objects and link them to fixed CVE numbers (see https://cyclonedx.org/guides/sbom/OWASP_CycloneDX-SBOM-Guide-en.pdf on page 48 ff for an example). But this seem to be a lot of effort to implement and the CVE scanner must support this and the naming+version ambiguity still remains. Best regards, Fabian Hanke Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -- Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62080): https://lists.yoctoproject.org/g/yocto/message/62080 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
