Re: [yocto] SPDX delivery
On Tue, May 28, 2024 at 1:01 AM Joshua Watt wrote: > > > On Mon, May 27, 2024, 11:47 AM Marta Rybczynska > wrote: > >> >> >> On Wed, May 15, 2024 at 8:09 PM Joshua Watt wrote: >> >>> On Wed, May 15, 2024 at 11:11 AM Marta Rybczynska >>> wrote: >>> > >>> > Hello all, >>> > As this discussion might be interesting to multiple people, I post it >>> to YP list and the OE architecture list. >>> > >>> > In the VEX work (the status will go out in a moment in a separate >>> message), we're collecting SPDX and CVE files for builds to re-run the CVE >>> checks later (potentially months later). The CVE check file is generated >>> for both the image and the build as it is (including the SDK). >>> > >>> > On the other hand, the SPDX archive is generated for the image only, >>> and contains only packages from the system image itself, omitting the build >>> system. This is possible for us to get all the partial SPDX files from the >>> build dir, but we do not expect the complete build dir to be kept for >>> months. >>> >>> Can you clarify what you mean by "build" here? We do generate SPDX for >>> the "native" recipes used during the build, and they are in the final >>> SPDX generated for an image, so we do have some idea of the "build" >>> tools used to generate an image. >>> >> >> >> Hello Joshua, >> This is still unclear to me. When I build an image eg bitbake >> core-image-minimal I get the spdx archive as expected: >> >> ./tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.spdx.tar.zst >> >> ./tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-20240522164207.spdx.tar.zst >> >> ./tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs.spdx.tar.zst >> >> >> ./tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs-20240522164207.spdx.tar.zst >> >> However, there's no archive for the world build (not going to mention how >> long it lasted). Is it on purpose? >> > > > Ya sorry. I wasn't trying to imply that we currently generate a SPDX > archive for world builds, just that we should be able to do so without to > much trouble > Thanks for clarification. I was confused and couldn't find the code... To clarify, what we have today is generation of the archive for rootfs images and in case of sdk build with populate_sdk. Is it correct? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63216): https://lists.yoctoproject.org/g/yocto/message/63216 Mute This Topic: https://lists.yoctoproject.org/mt/106118371/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] SPDX delivery
On Wed, May 15, 2024 at 8:09 PM Joshua Watt wrote: > On Wed, May 15, 2024 at 11:11 AM Marta Rybczynska > wrote: > > > > Hello all, > > As this discussion might be interesting to multiple people, I post it to > YP list and the OE architecture list. > > > > In the VEX work (the status will go out in a moment in a separate > message), we're collecting SPDX and CVE files for builds to re-run the CVE > checks later (potentially months later). The CVE check file is generated > for both the image and the build as it is (including the SDK). > > > > On the other hand, the SPDX archive is generated for the image only, and > contains only packages from the system image itself, omitting the build > system. This is possible for us to get all the partial SPDX files from the > build dir, but we do not expect the complete build dir to be kept for > months. > > Can you clarify what you mean by "build" here? We do generate SPDX for > the "native" recipes used during the build, and they are in the final > SPDX generated for an image, so we do have some idea of the "build" > tools used to generate an image. > Hello Joshua, This is still unclear to me. When I build an image eg bitbake core-image-minimal I get the spdx archive as expected: ./tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.spdx.tar.zst ./tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-20240522164207.spdx.tar.zst ./tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs.spdx.tar.zst ./tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs-20240522164207.spdx.tar.zst However, there's no archive for the world build (not going to mention how long it lasted). Is it on purpose? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2020): https://lists.openembedded.org/g/openembedded-architecture/message/2020 Mute This Topic: https://lists.openembedded.org/mt/106118369/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] SPDX delivery
On Wed, May 15, 2024 at 8:09 PM Joshua Watt wrote: > On Wed, May 15, 2024 at 11:11 AM Marta Rybczynska > wrote: > > > > Hello all, > > As this discussion might be interesting to multiple people, I post it to > YP list and the OE architecture list. > > > > In the VEX work (the status will go out in a moment in a separate > message), we're collecting SPDX and CVE files for builds to re-run the CVE > checks later (potentially months later). The CVE check file is generated > for both the image and the build as it is (including the SDK). > > > > On the other hand, the SPDX archive is generated for the image only, and > contains only packages from the system image itself, omitting the build > system. This is possible for us to get all the partial SPDX files from the > build dir, but we do not expect the complete build dir to be kept for > months. > > Can you clarify what you mean by "build" here? We do generate SPDX for > the "native" recipes used during the build, and they are in the final > SPDX generated for an image, so we do have some idea of the "build" > tools used to generate an image. > What I can see is a little strange and I am not able to attach it to clear terms. With an analysis done on core-image-minimal, for packages/recipes starting with 'a' and 'b', the following are there in the cve-check, but not in SPDX: bash (but bash-completion is in the SPDX) bzip2 (but bzip2-native is in the SPDX) Any idea why? > > > > > So, the question is, what people plan to archive from the build? Do we > need to archive the whole SPDX output too? This is an interesting question > for example in case of "world" builds.. > > The algorithm for creating the final SBoM for SPDX is actually pretty > generic: Given a single starting document that has some references to > external SPDX objects, it finds the documents that provide those > objects and adds those documents to the final SBoM. It then > re-calculates all of the (missing) external SPDX objects from the new > SBoM and repeats the process of adding documents to the SBoM until > either all references are satisfied, or the references are known to > not exist in the current build (which generates a warning, since it's > not really expected). > > The nice thing about this algorithm is that we can really generate a > SBoM for anything as long as you have the document (e.g. initial > objects) you want to start from. As such, we should be able to > generate SBoMs for world builds, individual packages, or just about > whatever we want. > > I'm wondering what makes sense to store: on one side, image is something that people flash on the device, so we definitely want to keep it. If there is a vulnerability in the compiler used to build, it does not necessarily affect the image (and you do not need to update it); except the case it affects the generated code. It makes then sense to store SDK and image status separately. I'd like to head opinions from people who use the SPDX generation, if there is a preference. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2011): https://lists.openembedded.org/g/openembedded-architecture/message/2011 Mute This Topic: https://lists.openembedded.org/mt/106118369/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] VEX work status
Hello all, We're close to the point to post RFC patches of the VEX work. As a reminder, we're working on storing SBOM/CVE information for later use and be able to re-run the cve-check in the future. To do that, we split out the nvd fetcher and cve-check from the YP builds to a separate tool. This tool can be used manually or integrated into the YP build system. To be able to generate that information, we needed to extract more data that was done previously, including package versions, CPE, any manual attestations from CVE_STATUS and related variables, detailed reasons for attestations and so on. Following other discussions and taking into account the NVD situation, we're integrating the "raw" CVE check using MITRE data (with possible overrides, some other repositories like the CISA one could be added with minimal effort). There will be two backends for the CVE check: the NVD backend and the "cve.org" backend. In the process, we also gain VEX support. The format resembles OpenVEX. However, the format does not support all the attestation types that we need so we add some, to avoid losing data. The file could be easily post-processed to remove the additions, but subsequent checks might be less accurate. Good news is, that the change surface is quite limited, so backports to LTS branches should be quite easy. It will be also possible to keep both the old and new code (there's an additional 'vex' class). If you have any questions, let me know. I expect the first RFC by the end of the month, if there are no last minute difficulties. Kind regards, Marta PS. There will be a more detailed status on the raw CVE check tomorrow. You can have a look atthe first POC showing how to do a CVE check using MITRE data directly (not using the data from the standalone tool in this version) in https://github.com/mrybczyn/cvelistv5-tools-poc/ and the corresponding overrides repo https://github.com/mrybczyn/cvelistV5-overrides -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2009): https://lists.openembedded.org/g/openembedded-architecture/message/2009 Mute This Topic: https://lists.openembedded.org/mt/106118733/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] SPDX delivery
Hello all, As this discussion might be interesting to multiple people, I post it to YP list and the OE architecture list. In the VEX work (the status will go out in a moment in a separate message), we're collecting SPDX and CVE files for builds to re-run the CVE checks later (potentially months later). The CVE check file is generated for both the image and the build as it is (including the SDK). On the other hand, the SPDX archive is generated for the image only, and contains only packages from the system image itself, omitting the build system. This is possible for us to get all the partial SPDX files from the build dir, but we do not expect the complete build dir to be kept for months. So, the question is, what people plan to archive from the build? Do we need to archive the whole SPDX output too? This is an interesting question for example in case of "world" builds.. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2008): https://lists.openembedded.org/g/openembedded-architecture/message/2008 Mute This Topic: https://lists.openembedded.org/mt/106118369/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] CVE program statement on the use of the new data format
https://medium.com/@cve_program/new-cve-record-format-enables-additional-data-fields-at-time-of-disclosure-82eef1d4035e Quote: The CVE Board is proud to announce that the CVE Program has evolved its record format to enhance automation capabilities and data enrichment. This format, utilized by CVE Services, facilitates the reservation of CVE IDs and the inclusion of data elements like CVSS, CWE, CPE, and other data into the CVE Record at the time of issuing a security advisory. This means the authoritative source (within their CNA scope) of vulnerability information — those closest to the products themselves — can accurately report enriched data to CVE directly and contribute more substantially to the vulnerability management process. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1999): https://lists.openembedded.org/g/openembedded-architecture/message/1999 Mute This Topic: https://lists.openembedded.org/mt/105800359/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] NVD status and ideas for a backup solution
On Mon, Apr 1, 2024 at 10:04 PM Marta Rybczynska wrote: > > Hello all, > The NVD has published an official status as promised at VulnCon: > https://nvd.nist.gov/general/news/nvd-program-transition-announcement > > This does not include much more information. NVD manager was > presenting at VulnCon, but without clear details on the way forward. > They are not stopping, but this is not sure when the analysis will be > back (they do the CPE and CVSS analysis plus handling emails that are > apparently in big numbers). > > Until there is a solution around NVD, I propose that we run a weekly > bulletin of which packages require update for our various branches, > taking from the CVE data, oss-security and other sources. If there are > more volunteers, we can do it more frequently. This is important work > and I would prefer not to be the only one doing this :) > > Let's discuss tomorrow during the call. > Hello all, An early prototype of how it might be working in the future: tooling: https://github.com/mrybczyn/cvelistv5-tools-poc overrides repo with direct fixes in CVE entries: https://github.com/mrybczyn/cvelistV5-overrides The tool is very simple, it just gets one product/vendor/version and outputs status of all CVEs found. It takes around 30s on my machine because it loads the whole CVE database out of 300k JSON files. I also have a version integrated with the data format of the VEX work, but it would require way more code to show. This snapshot gives the idea... Comments, ideas, fixes welcome! Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1993): https://lists.openembedded.org/g/openembedded-architecture/message/1993 Mute This Topic: https://lists.openembedded.org/mt/105274401/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Security tooling update: VEX, cve-check over SPDX and a plan "B" for the NVD situation
Hello all, Following numerous discussions in Seattle and otherwise (and having an OK from Richard to announce the work :), there is important work in progress on the tooling around CVE checking. 1. Addition of VEX: Vulnerability Exploitability eXchange (VEX) allows to have a machine-readable information of vulnerabilities in a project or build. The JSON format of cve-check is a kind of a VEX, and we are working on a more standard one. The final format is not confirmed yet. What we have looks more like OpenVEX for now. This may change to CSAF. In all cases, it will be easy to add another format if people are interested. 2. cve-check over SPDX(+VEX): it will be possible to run cve-check over an existing SPDX file (with existing VEX) and get an updated status. Imagine re-assesing vulnerabilities for an image built 6 months ago... 3. cve-check standalone: as a side-effect, cve-check will become a separate tool (yes, you could use it to check a particular package) 4. In the response to the NVD situation, and using the work done above, we have a prototype using the CVE raw data, not the NVD data. This requires an override database to fix issues with some CVE entries. The submission of RFCs will come in a few week's time. I'm planning to publish the "4" override database and a simple script as a PoC this week. Our local copy is somewhat-functional for regular scanning of our repositories. If you have pending work around cve-check or spdx please please put us in copy of your submission so that we can re-integrate. We have already branched-off. And finally, there's the open letter you can sign: https://lists.openembedded.org/g/openembedded-architecture/message/1990 Let's discuss during the call today or by the mailing list if you have any questions! Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1991): https://lists.openembedded.org/g/openembedded-architecture/message/1991 Mute This Topic: https://lists.openembedded.org/mt/105689358/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] NVD status and ideas for a backup solution
Hello all, The NVD has published an official status as promised at VulnCon: https://nvd.nist.gov/general/news/nvd-program-transition-announcement This does not include much more information. NVD manager was presenting at VulnCon, but without clear details on the way forward. They are not stopping, but this is not sure when the analysis will be back (they do the CPE and CVSS analysis plus handling emails that are apparently in big numbers). Until there is a solution around NVD, I propose that we run a weekly bulletin of which packages require update for our various branches, taking from the CVE data, oss-security and other sources. If there are more volunteers, we can do it more frequently. This is important work and I would prefer not to be the only one doing this :) Let's discuss tomorrow during the call. Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1983): https://lists.openembedded.org/g/openembedded-architecture/message/1983 Mute This Topic: https://lists.openembedded.org/mt/105274401/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto-security] [Openembedded-architecture] YP Security team document
On Tue, Oct 17, 2023 at 1:02 PM Ross Burton wrote: > > On 17 Oct 2023, at 11:24, Richard Purdie via lists.openembedded.org > wrote: > > > > On Tue, 2023-10-17 at 12:09 +0200, Marta Rybczynska wrote: > >> Hello all, > >> This has been a moment working on the YP security team and I think > >> that the current version of the document contains everything that it > >> should have to get it a go. Please have a look and let me know if you > >> have any last comments: > >> https://wiki.yoctoproject.org/wiki/Security_private_reporting > >> > >> I will then start transcription to the docs. > > > > I made a few small wording tweaks and added a guide of what we'd like > > to cover with security team membership. Hope that is all ok! > > > > Otherwise looks good to me. > > Agreed, looks good. Hello, The main part of the document is on its way to the yocto-docs repo. To finish the chapter I have now added a section on embargoes: https://wiki.yoctoproject.org/wiki/Security_private_reporting If it looks OK for you, it will come in another patch to the docs. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1813): https://lists.openembedded.org/g/openembedded-architecture/message/1813 Mute This Topic: https://lists.openembedded.org/mt/102270239/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto-security] [Openembedded-architecture] Adding SECURITY.md (Was: Question: supported layers for security processes)
On Tue, Oct 24, 2023 at 4:41 PM Marta Rybczynska via lists.yoctoproject.org wrote: > > On Tue, Oct 24, 2023 at 2:47 PM Richard Purdie > wrote: > > > > > > > > On 10/20/23 05:49, Richard Purdie via lists.openembedded.org wrote: > > > > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote: > > > > > While working on multiple aspects of security processes, one question > > > > > comes back frequently: which are the layers we support with those > > > > > processes? This has impact on the number of SECURITY.md I will be > > > > > submitting, of configuring any CVE synchronization work etc. > > > > > > > > > > The YP download page offers a download of poky. The release > > > > > documentation > > > > > https://docs.yoctoproject.org/migration-guides/index.html#release-information > > > > > nor the Release page (https://wiki.yoctoproject.org/wiki/Releases) > > > > > does not exactly list layers covered. > > > > > > > > > > Is it poky only? Poky + meta-openemedded? With some BSP layers? > > > > > > > > > > This has a general impact, because I assume that layers maintained > > > > > "externally" might have different security contacts, for example. > > > > > > > > > > Do we have that documented somewhere so that we can reference in the > > > > > security documentation? > > > > It will be for the layer maintainers to decide what to do about this > > > > file. From the Yocto Project perspective, we should cover bitbake, > > > > meta-yocto, openembedded-core (done) and yocto-docs. > > > > > > > > Looking over https://git.yoctoproject.org/ we should add one to meta- > > > > mingw as a tested layer. I've asked meta-gplv2 move to other layers. > > > > > > > > We should probably mention this issue to the other layer maintainers, > > > > maybe on the architecture list and perhaps also open a bug to make > > > > SECURITY.md a requirement for Yocto Project Compatible status? > > > > > > > > We should also add it to some of the code/tools repositories, in > > > > particular: > > > > > > > > auto-upgrade-helper, buildhistory-web, error-report-web, git-refinery- > > > > web, layerindex-web, pseudo, psplash, ptest-runner2, update-rc.d, > > > > swatbot, yocto-autobuilder-helper, yocto-autobuilder2. > > > > > > > > If we're happy with the test in OE-Core, I can update several of these > > > > to make the work a little easier? > > > > > > > > We should email the maintainers for opkg/opkg-utils as well (opkg > > > > mailing list). > > > > > > That's me. :) > > > > > > The request here is that I add a SECURITY.md with instructions for how > > > to file security issues against opkg, a la the same document that is > > > already in OE-core; right? > > > > > > Would y'all prefer if private security emails for opkg went to > > > `secur...@yoctoproject.org`? Otherwise, I'll default to my email directly. > > > > I've just been trying to work out what we're doing with other repos > > before replying. > > > > For "tools", I've gone with simply: > > > > """ > > How to Report a Potential Vulnerability? > > > > > > If you would like to report a public issue (for example, one with a released > > CVE number), please report it using the > > [https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security > > Bugzilla]. > > If you have a patch ready, submit it following the same procedure as any > > other > > patch as described in README.md. > > > > If you are dealing with a not-yet released or urgent issue, please send a > > message to security AT yoctoproject DOT org, including as many details as > > possible: the layer or software module affected, the recipe and its version, > > and any example code, if available. > > > > """ > > e.g. > > > > https://git.yoctoproject.org/swatbot/commit/?id=961b8c10da89f011e79834c160196057a4233170 > > > > There is a second paragraph about release but it only makes sense in > > metadata repositories (e.g. meta-yocto or meta-mingw). > > > > You would be more than welcome to put your name as the maintainer > > there. We've gone with the security l
Re: [Openembedded-architecture] Question: supported layers for security processes
On Tue, Oct 24, 2023 at 2:47 PM Richard Purdie wrote: > > > > > On 10/20/23 05:49, Richard Purdie via lists.openembedded.org wrote: > > > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote: > > > > While working on multiple aspects of security processes, one question > > > > comes back frequently: which are the layers we support with those > > > > processes? This has impact on the number of SECURITY.md I will be > > > > submitting, of configuring any CVE synchronization work etc. > > > > > > > > The YP download page offers a download of poky. The release > > > > documentation > > > > https://docs.yoctoproject.org/migration-guides/index.html#release-information > > > > nor the Release page (https://wiki.yoctoproject.org/wiki/Releases) > > > > does not exactly list layers covered. > > > > > > > > Is it poky only? Poky + meta-openemedded? With some BSP layers? > > > > > > > > This has a general impact, because I assume that layers maintained > > > > "externally" might have different security contacts, for example. > > > > > > > > Do we have that documented somewhere so that we can reference in the > > > > security documentation? > > > It will be for the layer maintainers to decide what to do about this > > > file. From the Yocto Project perspective, we should cover bitbake, > > > meta-yocto, openembedded-core (done) and yocto-docs. > > > > > > Looking over https://git.yoctoproject.org/ we should add one to meta- > > > mingw as a tested layer. I've asked meta-gplv2 move to other layers. > > > > > > We should probably mention this issue to the other layer maintainers, > > > maybe on the architecture list and perhaps also open a bug to make > > > SECURITY.md a requirement for Yocto Project Compatible status? > > > > > > We should also add it to some of the code/tools repositories, in > > > particular: > > > > > > auto-upgrade-helper, buildhistory-web, error-report-web, git-refinery- > > > web, layerindex-web, pseudo, psplash, ptest-runner2, update-rc.d, > > > swatbot, yocto-autobuilder-helper, yocto-autobuilder2. > > > > > > If we're happy with the test in OE-Core, I can update several of these > > > to make the work a little easier? > > > > > > We should email the maintainers for opkg/opkg-utils as well (opkg > > > mailing list). > > > > That's me. :) > > > > The request here is that I add a SECURITY.md with instructions for how > > to file security issues against opkg, a la the same document that is > > already in OE-core; right? > > > > Would y'all prefer if private security emails for opkg went to > > `secur...@yoctoproject.org`? Otherwise, I'll default to my email directly. > > I've just been trying to work out what we're doing with other repos > before replying. > > For "tools", I've gone with simply: > > """ > How to Report a Potential Vulnerability? > > > If you would like to report a public issue (for example, one with a released > CVE number), please report it using the > [https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security > Bugzilla]. > If you have a patch ready, submit it following the same procedure as any other > patch as described in README.md. > > If you are dealing with a not-yet released or urgent issue, please send a > message to security AT yoctoproject DOT org, including as many details as > possible: the layer or software module affected, the recipe and its version, > and any example code, if available. > > """ > e.g. > > https://git.yoctoproject.org/swatbot/commit/?id=961b8c10da89f011e79834c160196057a4233170 > > There is a second paragraph about release but it only makes sense in > metadata repositories (e.g. meta-yocto or meta-mingw). > > You would be more than welcome to put your name as the maintainer > there. We've gone with the security list/bugzilla as the project > defaults but the maintainer makes sense when they're willing/able as > they're better placed to handle this. > > The key thing is to get a SECURITY file in place. > > If you could take care of opkg/opkg-utils that would be great! > > Cheers, > > Richard > > > Following the discussion, I've added a wiki page discussing usage of SECURITY.md: https://wiki.yoctoproject.org/wiki/SECURITY_file Please comment/adjust. When we agree on this text, I will transcribe it to the documentation. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1806): https://lists.openembedded.org/g/openembedded-architecture/message/1806 Mute This Topic: https://lists.openembedded.org/mt/102077441/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] [yocto-security] Question: supported layers for security processes
On Fri, Oct 20, 2023 at 5:25 PM akuster808 wrote: > > > > On 10/20/23 5:49 AM, Richard Purdie wrote: > > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote: > >> While working on multiple aspects of security processes, one question > >> comes back frequently: which are the layers we support with those > >> processes? This has impact on the number of SECURITY.md I will be > >> submitting, of configuring any CVE synchronization work etc. > >> > >> The YP download page offers a download of poky. The release > >> documentation > >> https://docs.yoctoproject.org/migration-guides/index.html#release-information > >> nor the Release page (https://wiki.yoctoproject.org/wiki/Releases) > >> does not exactly list layers covered. > >> > >> Is it poky only? Poky + meta-openemedded? With some BSP layers? > >> > >> This has a general impact, because I assume that layers maintained > >> "externally" might have different security contacts, for example. > >> > >> Do we have that documented somewhere so that we can reference in the > >> security documentation? > > It will be for the layer maintainers to decide what to do about this > > file. From the Yocto Project perspective, we should cover bitbake, > > meta-yocto, openembedded-core (done) and yocto-docs. > > > > Looking over https://git.yoctoproject.org/ we should add one to meta- > > mingw as a tested layer. I've asked meta-gplv2 move to other layers. > > > > We should probably mention this issue to the other layer maintainers, > > maybe on the architecture list and perhaps also open a bug to make > > SECURITY.md a requirement for Yocto Project Compatible status? > Why? My layers only have upstream components. I would just tell an > individual to go to the upstream source and deal with those maintainers. > I bring no value being in the middle. > SECURITY.md is a (practically) standarized way of saying how to to contact a given project when someone has a non-public security issue. Saying in the file that you want to report upstream instead is a fair game, but won't work in two cases: - if the issue comes from locally maintained patches (eg. badly applied patch, a bug in a specific patch) - in a case of a multi-project embargo Today the security researcher would probably mail the maintainer (if any easy to find in the README or so), and if they can't find any, just drop the info on a public mailing list (or IRC). My idea is to have a SECURITY.md and definitely, allow every layer to adjust to their needs. Hope that makes it clear, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1804): https://lists.openembedded.org/g/openembedded-architecture/message/1804 Mute This Topic: https://lists.openembedded.org/mt/102083332/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Question: supported layers for security processes
Hello, While working on multiple aspects of security processes, one question comes back frequently: which are the layers we support with those processes? This has impact on the number of SECURITY.md I will be submitting, of configuring any CVE synchronization work etc. The YP download page offers a download of poky. The release documentation https://docs.yoctoproject.org/migration-guides/index.html#release-information nor the Release page (https://wiki.yoctoproject.org/wiki/Releases) does not exactly list layers covered. Is it poky only? Poky + meta-openemedded? With some BSP layers? This has a general impact, because I assume that layers maintained "externally" might have different security contacts, for example. Do we have that documented somewhere so that we can reference in the security documentation? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1797): https://lists.openembedded.org/g/openembedded-architecture/message/1797 Mute This Topic: https://lists.openembedded.org/mt/102077441/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] YP Security team document
Hello all, This has been a moment working on the YP security team and I think that the current version of the document contains everything that it should have to get it a go. Please have a look and let me know if you have any last comments: https://wiki.yoctoproject.org/wiki/Security_private_reporting I will then start transcription to the docs. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1790): https://lists.openembedded.org/g/openembedded-architecture/message/1790 Mute This Topic: https://lists.openembedded.org/mt/102014565/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Yocto Project security work in progress: call for contributions
Hello all, There's an ongoing work on the YP security and we have had an interesting discussion during the weekly meeting on September 26. Slides used are available from the wiki [1]. If you're interested i security subjects, please comment on the content. Two processes are currently in the works: - the vulnerability reporting process and the security team [2] (complete, ready for review) - the CVE synchronization [3] (work in progress) They are working for your feedback! We are also searching for people who will like to join the group experimenting with CVE work synchronization. Kind regards, Marta [1] https://wiki.yoctoproject.org/wiki/File:Yocto_Project_Security_-_26_09_2023.pdf [2] https://wiki.yoctoproject.org/wiki/Security_private_reporting [3] https://wiki.yoctoproject.org/wiki/Synchronization_CVEs -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1786): https://lists.openembedded.org/g/openembedded-architecture/message/1786 Mute This Topic: https://lists.openembedded.org/mt/101663407/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] [yocto] Security processes: YP needs
On Wed, 27 Sept 2023, 12:05 Reyna, David, wrote: > Hi Marta! > > > What about 11am Pacific on tomorrow (28 Sept or Oct 3)? > > Let us aim for October 3 so that I can prepare a full demo.. > > > I think that you have meant 10am to 2PM, otherwise 1am Pacific would > work very well for me too > > I actually did mean 2:00 am Pacific. I do work with our India team, so I > am often up late to sync with them.. > > > As discussed yesterday in the call, there are some other people who seem > interested. > > What time zone are you in? > I believe Ross is in England (UTC) > I know that Randy is in Ottawa. > > If anyone else wants to join, that would be great!. They should ping us > and I can send the Zoom link. I do not want to send that link blindly to > the full mail list. > I'm in CEST (Central European zone). If we aim for the 3rd then let's stay for late afternoon for me. I let Ross, Randy and everyone else interested to express their preferences. > > I'm going to add the missing file for the test next week, the tool needs > a script to download 2023 data. > > That file is part of my code update, so you can get that for free. > Thanks! David > > -Original Message- > From: Marta Rybczynska > Sent: Wednesday, September 27, 2023 12:18 AM > To: Reyna, David > Cc: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-c...@lists.openembedded.org>; > openembedded-architecture@lists.openembedded.org; > yo...@lists.yoctoproject.org; MacLeod, Randy ; > Richard Purdie ; Steve Sakoman < > st...@sakoman.com>; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP > needs > > Hi David, > Thank you very much for the description and the offer to get a demo. > As discussed yesterday in the call, there are some other people who > seem interested. > > > PROPOSAL 1: If the full triage is too much to bite off to start with, > perhaps using it to track and coordinate work will bring immediate benefit. > > This is the reason I want to test how much time it takes. > > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. > I am available pretty much anytime between 10:00 am Pacific to 2:00 am > Pacific. > > That would be nice. What about 11am Pacific on tomorrow (28 Sept or > Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific > would work very well for me too :P > > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my > current implementation level from Wind River (with the Wind River specific > modules left out of course :-) > > That would be great. I'm going to add the missing file for the test > next week, the tool needs a script to download 2023 data. > > Kind regards, > Marta > > On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via > lists.openembedded.org > wrote: > > > > Hi Marta, > > > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > > > There are many ways to use the SRTool. > > (a) The original design was to perform 100% triage of incoming CVEs. > This was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > > (b) The main limitation with the SRTool for Yocto Project was the > lack of integration with Bugzilla (Ross ran out of time) > > * This is the crucial other half of the workflow > > * There is the automatic creation of appropriate defect records for > investigation > > * There is also the automatic tracking of the overall CVE status, > both CVEs in progress and the CVEs completed > > * Wind River has an extension for full integration with Jira, and > that saves weeks of work for the CVE management > > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate > of domains > > (d) The SRTool has a user model > > * Together with Bugzilla, it is easy to track single people and > even multiple people working on CVEs > > (e) The SRTool also has the built-on ability to look up the CVE status > from other distributions (Red Hat, Debian, ...) so that one can get a peek > of existing triages and resolutions > > (f) The SRTool is build like Toaster on top of Django, so development > and debugging skills for Toaster immediate apply > > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support
Re: [Openembedded-architecture] [yocto] Security processes: YP needs
Hi David, Thank you very much for the description and the offer to get a demo. As discussed yesterday in the call, there are some other people who seem interested. > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. This is the reason I want to test how much time it takes. > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. That would be nice. What about 11am Pacific on tomorrow (28 Sept or Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific would work very well for me too :P > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) That would be great. I'm going to add the missing file for the test next week, the tool needs a script to download 2023 data. Kind regards, Marta On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via lists.openembedded.org wrote: > > Hi Marta, > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > There are many ways to use the SRTool. > (a) The original design was to perform 100% triage of incoming CVEs. This > was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > (b) The main limitation with the SRTool for Yocto Project was the lack of > integration with Bugzilla (Ross ran out of time) > * This is the crucial other half of the workflow > * There is the automatic creation of appropriate defect records for > investigation > * There is also the automatic tracking of the overall CVE status, both > CVEs in progress and the CVEs completed > * Wind River has an extension for full integration with Jira, and that > saves weeks of work for the CVE management > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate of > domains > (d) The SRTool has a user model > * Together with Bugzilla, it is easy to track single people and even > multiple people working on CVEs > (e) The SRTool also has the built-on ability to look up the CVE status from > other distributions (Red Hat, Debian, ...) so that one can get a peek of > existing triages and resolutions > (f) The SRTool is build like Toaster on top of Django, so development and > debugging skills for Toaster immediate apply > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support for example CVE Scanner integration > (h) The SRTool also has report generation (in text, CSV, and Excel) in > addition to email notification support. > (i) There is also a "private" model for CVEs under embargo, with strict > access control lists. > > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) > > David > > BTW, I also support an extension to the SRTool that manages CVE scanning of > build images, with hooks to a number existing CVE scanners (e.g. Trivy) in > addition to other vulnerability metrics. This is probably out of scope to YP > at this time, but it is perhaps something to grow in to. > > -Original Message- > From: yo...@lists.yoctoproject.org On Behalf > Of Marta Rybczynska via lists.yoctoproject.org > Sent: Wednesday, September 13, 2023 4:52 AM > To: yocto-secur...@lists.yoctoproject.org; OE-core > ; > openembedded-architecture@lists.openembedded.org; yo...@lists.yoctoproject.org > Cc: Richard Purdie ; Steve Sakoman > ; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: [yocto] Security processes: YP needs > > Hello, > I've been working recently on collecting what works and what doesn't > in YP security processes. The goal is to go forward and define an > actionable strategy! > > Today, I'd like to share with you the summary of what I have heard as > needs from several people (those in Cc:). > > I want the
Re: [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart wrote: > > Thanks for driving this Marta. Internally and externally, it feels like > we're just on the cusp of everyone *suddenly caring* about our security > response strategy. So it's good to see that we're making moves in that > direction. > Thank you Alex! > > More responses inline. > > On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: > > * CVEs: Visibility if YP is vulnerable or not > > > > People want to be able to check/look up a specific CVE; it might be a > > CVE unrelated to YP > > (eg. package not included, Windows issue). The cve-checker result is a > > part of the solution, but people also want to know which CVEs do not > > apply. > > I'm not sure I understand this usecase. Is there a reason those people > can't/won't just lookup the CVE on the NIST site? > Mark's answer is clarifying that. I'll add that this is a requirement I have heard from multiple sources. People might look up CVE/NIST, but that takes time if you are required to look up all CVEs. If we have common data, we avoid duplicate work. > > * CVEs: synchronization of the work on fixes > > > > Currently, there is no synchronization; multiple parties might be > > working on the same fix while nobody is working on another. There > > might be duplication of work. > > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > Has there been any discussion of adopting the OpenVEX document standard > that the Chainguard guys are putting together? [1] It seems like the VEX > use-cases align well with our needs around tracking and coordinating CVE > response between YP member and individual developers. > We might decide to use it. However, openVEX a way to output the data we have/will have (the conclusion), not a way to sync up the work. > > > * Triaging of security issues > > > > Related to CVE fixes and includes issues reported directly to the YP. > > Some issues are more likely to be serious for embedded products > > (attack by network), so not all has the same priority. > > I'll note here that some of us are sinners and do actually support > network-attached (and internet-attached) embedded devices. :) > > But the greater point of OS vendors being able to triage and assign > vendor-specific severities to incoming issues is absolutely important to > my use-cases. > This is an important point. YP is generic and YP assesment of severity might be different than the one from a vendor. It means that our process should be flexible enough that a vendor can take the data and assign their own severity. > > > > * Visibility of the security work of the YP > > > > There is much work on security in the YP, but it lacks visibility. > > Is there a common nexus for this work? eg. do most of the folks who are > doing security work tend to congregate on the security sublist? I'd like to know :) This thread is a big cross-post (and sorry for that, but I need to reach the whole audience), for further discussions I'd like to invite all to a dedicate list. > > > * Additional tooling > > > > We could add additional tooling: a template on how to add cve-check to > > the CI (possibly > > a different one than the autobuilder), analyze the result, and extend > > our tooling to their layers... > > It is also related to the "Architecture" topic below. > > Can you expand on what you mean here? Is this usecase about extending > the existing tooling into the generic CI processes that YP members are > using, or about expanding the tooling in the YP's indigenous CI? This is a requirement assembling multiple ones. Many people mentioned that additional tooling would be needed and/or helpful. A CI template is an example here. I'm interested in your list of tooling that would be important or useful to have. Preferably related to processes that are currently done in-house and that we can make more generic and share the work. > > > * Presence on pre-notification lists and receiving information before > > the vulnerability gets public > > > > YP currently depends on public data. Principal distributions receive > > the information before > > a vulnerability becomes public. It requires (in short) private > > reporting, a security team, and a track > > of excellent security record. > > > > * Becoming a CNA (be able to assign CVEs) > > > > Needed if we want to assign CVEs to the software of the YP, like > > autobuilder, Toaster etc. > > I'm also interested in this, as the maintainer of our opkg fork. So far, > I haven't had to respond to a CVE against the project, but that won't > last forever. CVEs against a fork, t
Re: [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli wrote: > > Hi, > > On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > > Hello, > > I've been working recently on collecting what works and what doesn't > > in YP security processes. The goal is to go forward and define an > > actionable strategy! > > > > Today, I'd like to share with you the summary of what I have heard as > > needs from several people (those in Cc:). > > > > I want the community to comment and tell us what you find important > > and what you'd like to see added or changed from this list. > > Since most users take poky reference distro and combine it with a number > of open source and closed source BSP and other meta layers and build > systems to produce SW for products, they also need documentation and tooling > so that they can replicate the Yocto Project security processes and use the > available tools. Do you also mean that we should make sure Poky follows security best practices? Noted the point on documenting the way process works/will work so other teams can extend it to their layer. > > I think most of the documentation around the tools and processes is in place > already. > Having maintained and shipped from a non-maintained poky branch, I can just > say > thank you to all who participated in the upstream work to get security > vulnerability > detection and fixing possible! > Out of curiosity, what have you backported? cve-check? LTS work? > That being said, extending the CVE scanning and status tracking work to > include more > open source layers would be nice both for the maintainers and for the users > of those > layers. Using some random old branch of meta-foo may not be so safe. Maybe add > this data to layer-index? > We have Yocto Project Compatible already. Do we need something else? Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1755): https://lists.openembedded.org/g/openembedded-architecture/message/1755 Mute This Topic: https://lists.openembedded.org/mt/101334933/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Security processes: YP needs
Hello, I've been working recently on collecting what works and what doesn't in YP security processes. The goal is to go forward and define an actionable strategy! Today, I'd like to share with you the summary of what I have heard as needs from several people (those in Cc:). I want the community to comment and tell us what you find important and what you'd like to see added or changed from this list. * CVEs: Visibility if YP is vulnerable or not People want to be able to check/look up a specific CVE; it might be a CVE unrelated to YP (eg. package not included, Windows issue). The cve-checker result is a part of the solution, but people also want to know which CVEs do not apply. * CVEs: synchronization of the work on fixes Currently, there is no synchronization; multiple parties might be working on the same fix while nobody is working on another. There might be duplication of work. Ross has https://wiki.yoctoproject.org/wiki/CVE_Status * Triaging of security issues Related to CVE fixes and includes issues reported directly to the YP. Some issues are more likely to be serious for embedded products (attack by network), so not all has the same priority. * Private security communication A way to send a notification of a non-public security issue. For researchers, other projects etc. The security alias exists, but only some people know about its existence. * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. * Documentation Related to visibility. We need easy-to-find documentation of subjects like submitting a CVE fix, reporting a private issue, and how our processes work... This documentation should address people who are not regular contributors. * Additional tooling We could add additional tooling: a template on how to add cve-check to the CI (possibly a different one than the autobuilder), analyze the result, and extend our tooling to their layers... It is also related to the "Architecture" topic below. * Architecture work Security if more than CVE fixes. We also have what is happening in meta-security: hardening, compiler option, secure package configuration, use of code coverage tools, and so on * SRTool We might decide to use it again. It allows one to do much but requires constant commitment. * Presence on pre-notification lists and receiving information before the vulnerability gets public YP currently depends on public data. Principal distributions receive the information before a vulnerability becomes public. It requires (in short) private reporting, a security team, and a track of excellent security record. * Becoming a CNA (be able to assign CVEs) Needed if we want to assign CVEs to the software of the YP, like autobuilder, Toaster etc. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1747): https://lists.openembedded.org/g/openembedded-architecture/message/1747 Mute This Topic: https://lists.openembedded.org/mt/101334933/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Adding more information to the SBOM
Dear all, (cross-posting to oe-core and *-architecture) In the last months, we have worked in Oniro on using the create-spdx class for both IP compliance and security. During this work, Alberto Pianon has found that some information is missing from the SBOM and it does not contain enough for Software Composition Analysis. The main missing point is the relation between the actual upstream sources and the final binaries (create-spdx uses composite sources). Alberto has worked on how to obtain the missing data and now has a POC. This POC provides full source-to-binary tracking of Yocto builds through a couple of scripts (intended to be transformed into a new bbclass at a later stage). The goal is to add the missing pieces of information in order to get a "real" SBOM from Yocto, which should, at a minimum: - carefully describe what is found in a final image (i.e. binary files and their dependencies), since that is what is actually distributed and goes into the final product; - describe how such binary files have been generated and where they come from (i.e. upstream sources, including patches and other stuff added from meta-layers); provenance is important for a number of reasons related to IP Compliance and security. The aim is to become able to: - map binaries to their corresponding upstream source packages (and not to the "internal" source packages created by recipes by combining multiple upstream sources and patches) - map binaries to the source files that have been actually used to build them - which usually are a small subset of the whole source package With respect to IP compliance, this would allow to, among other things: - get the real license text for each binary file, by getting the license of the specific source files it has been generated from (provided by Fossology, for instance), - and not the main license stated in the corresponding recipe (which may be as confusing as GPL-2.0-or-later & LGPL-2.1-or-later & BSD-3-Clause & BSD-4-Clause, or even worse) - automatically check license incompatibilities at the binary file level. Other possible interesting things could be done also on the security side. This work intends to add a way to provide additional data that can be used by create-spdx, not to replace create-spdx in any way. The sources with a long README are available at https://gitlab.eclipse.org/eclipse/oniro-compliancetoolchain/toolchain/tinfoilhat/-/tree/srctracker/srctracker What do you think of this work? Would it be of interest to integrate into YP at some point? Shall we discuss this? Marta and Alberto -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1634): https://lists.openembedded.org/g/openembedded-architecture/message/1634 Mute This Topic: https://lists.openembedded.org/mt/93678489/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
