[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] Security processes: YP needs
From:       "Mikko Rapeli" <mikko.rapeli () linaro ! org>
Date:       2023-09-15 6:38:22
Message-ID: ZQP73vJtIeTv/Xbi () nuoska
[Download RAW message or body]

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 <mikko.rapeli@linaro.org> 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/4454510 Group Owner: \
                openembedded-architecture+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub \
                [openembedded-architecture@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread]