Hi, On Fri, Sep 15, 2023 at 08:17:41AM +0200, Marta Rybczynska wrote: > On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli <[email protected]> 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?
Yes, and it mostly does. > 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? I backported the cve-check and related tooling and then looked after the subset of SW components that were used for certain products. Then fixing the findings required either backports from other stable/LTS branches or master. Using custom patches to old SW component versions was pretty easy to avoid in most cases. In cases like curl, it makes sense for users to reduce the attack surface and reduce the set of available features so that things like ftp are not enabled if not used. CVEs were then deemed to not affect the product configuration and set to ignored also for cve-check. > > 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? I know it is layer maintainers job to look after build, QA and CI for their layers but adding cve-checker runs with public results would be nice. I'm a bit torn on the layer compatibility settings, for example, since they make it harder to use newer layer branches on older poky releases, which maybe a really good idea for security patches and long term maintenance. Yes these are custom configurations and maintainers don't test these, but in many cases it will just work. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1757): https://lists.openembedded.org/g/openembedded-architecture/message/1757 Mute This Topic: https://lists.openembedded.org/mt/101334933/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
