> -----Original Message----- > From: [email protected] > <[email protected]> On Behalf Of Richard > Purdie via lists.openembedded.org > Sent: den 5 februari 2026 19:03 > To: [email protected]; [email protected]; > [email protected] > Cc: David Partain <[email protected]>; Marta Rybczynska > <[email protected]> > Subject: Re: [security-discussions] [Openembedded-architecture] Proposal for > coordination on work for CVE backports > > On Thu, 2026-02-05 at 11:57 -0500, Philip Balister via lists.openembedded.org > wrote: > > I am going to make the suggestion: > > > > Let's try what Daniel suggests. > > > > Far to often we get bogged down in conversations about what the correct > > thing is to do, and lose track of the fact we need to do something and > > see what works. The list he suggests only has a handful of posts and if > > it doesn't get any traction, I will suggest we remove it. Until, lets > > see of people working in this eco system can use it to coordinate work. > > > > If we can get people coordinating over email, then we need a larger > > conversation about getting people to work together. > > Your call but I'm not particularly happy about this. This basically > says that when people feel like it they can bypass/ignore bodies like > the TSC and there isn't really going to be any > responsibility/fallback/oversight. I would *love* to be able to do many > things more freely yet I am permanently tied up in so much red tape I > feel like I'm drowning and can't get anything done. > > The security-discussions list has sat for a number of months with a > single post. It seems the idea didn't work out and yet the list is > still there and it causes confusions with other "security" lists. Is > something going to be done about that or are we still hoping it might > work out? Is someone going to drive that? > > Cheers, > > Richard
I am extremely skeptical for this proposition to work. I can of course not speak for anyone else, but looking at the process of how this kind of problems are solved within our company, it goes something like this: 1. A security problem is discovered in one of the components in our platform. 2. The responsible development team is notified about it. They are now on the clock as they must have a solution integrated within a set time frame. 3. If it is an open source component, then they (hopefully) look for solutions upstream. 4. If a solution is found, then they either update the component to a newer version, or backport the patch. 5. If no solution exists, then they solve it themselves (and I do hope they contribute it upstream). 6. Our platform is updated with the solution, and the team moves on. 7. Eventually I come along and upgrade the version of OE that we are using. If the problem has then been solved upstream, this typically results in a conflict and I resolve it by removing our local fix. The likelihood of me getting all our development teams to start communicating with a community where most of them are not involved during the above process is slim to none. Especially as, in most cases, we cannot wait for the next Yocto release to be released and integrated to our platform anyway. //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2245): https://lists.openembedded.org/g/openembedded-architecture/message/2245 Mute This Topic: https://lists.openembedded.org/mt/117655357/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
