Hello,
The security-discussion@ mailing list was created to facilitate
discussion of security work *between* ecosystems, including OE,
buildroot, RTOSes and the like. The OE Board agreed to that as a neutral
place where people from other projects may come together. Philip can
correct me if he understood it differently.
One of the ideas that got most support was to use it for sync on known
vulnerability backports, collect existing backport patches, communicate
on commit hashes (especially when they are not in the CVE/NVD entry) and
generally discuss the internals. However, even with the verbal support,
the idea did not take off.
What Daniel proposes is something YP-specific, so in my opinion it
should be done on YP-specific lists (we already have appropriate ones).
I'm not against trying it again. However, we have already made an
attempt in the wiki. That didn't work (people didn't use is).
Because of that, I think that we need to investigate more what the
reason of the previous outcome was, before trying again. Quite likely
possible reasons are somewhere on the Richard's list. We may make a
proposal, but teams that do such backports will only follow if their
management agrees. They will also need to agree on training every new
developer on that procedure (and the backporting job is showing high
turnover). And, finally, we need to reach people actually doing the
work. Because of all those reasons, I think it is a discussion for the
YP, either the membership or the YP TSC, also because many of the teams
doing backports are YP members.
Kind regards,
Marta
On 2/5/26 10:05 AM, Richard Purdie via lists.openembedded.org wrote:
Hi Daniel,
On Thu, 2026-02-05 at 08:23 +0000, Daniel Turull via lists.openembedded.org
wrote:
I would like to propose a way of working on coordinating CVE
backports to reduce wasted effort.
Problem:
Now with the CRA more are more companies will start sending backports
to the different LTS branches for oe-core and meta-openembedded. This
will make 2 or more people working on the same correction, resulting
on a waste of time for the persons that do not send the patch first.
This time could have been invested in fixing another CVE, which then
whole community will benefit.
We discussed this in a small group in the OSS EU in Amsterdam last
August and Marta ask to create the a new mailing
listhttps://lists.openembedded.org/g/security-discussions
So far, no one has been using the mailing list.
As far as I know, that list was created directly by the OE board and
wasn't discussed with the OE or Yocto Project TSCs, just to see what
happened. The challenge with doing that is that nobody was really
consulted and there wasn't much communication around it.
The OE TSC should really therefore defer to the OE board and ask it
what it's plans are. The Yocto Project isn't involved.
Proposal:
To use the mailing list when someone is starting to work on a
backport and announce it. This is completely optional but could help
others to prevent stating working on the same backport. If there is
no activity, let’s say within a week, anyone could take the lead. The
person who initiated can also indicate the status if he/she gets
stuck and needs help.
The list can also be used to coordinate work, for example if a CVE is
complex and the person working on it gets stuck.
Format:
Subject: Starting oe-core backport for CVE-XXXX-XXXXXX for component
X version Y
Example:
Subject: Starting oe-core backport for CVE-2025-68276 for avahi 0.8
Once we agree, I can write the documentation, so it is also
visiblehttps://docs.yoctoproject.org/dev/security-manual/index.html
Do you think is a good idea? Any comments or suggestions of
improvements?
Sharing the proposal is a good start but I'd like to hear from Marta
about why this was setup and why the TSCs weren't involved. I actually
hate to ask that question as it does start to pull more process into
this and I don't like how much work the existing process can cause me
in particular. That said, changing the project's security processes
without the involvement of the TSCs doesn't seem right to me. I end up
being one of the people who tries to follow the rules and procedures we
setup, I'd love to just bypass them myself!
Moving past the process issues and looking at the proposal itself, I
think I'd observe that:
* we want to try and have as little overhead around fixing CVEs as we
can.
* the more process we put around it, particularly if we start insisting
on it, the fewer contributions we might get
* how (and who) would handle someone who says they start things but
never submit them?
* if someone mentions on the list they're working on it but someone
else does it first, which one gets merged?
* some existing contributors struggle to get management by in for
sharing the CVE fixes, this may make it harder to contribute for them
* some companies don't want to announce the fact they're aware of a
security issue as for example that has implications under the CRA
* some companies also view what they have people working on, or how
long it takes as commercially sensitive
We really need the buy in from the people writing and submitting these
changes so I'd be interested to hear from them in particular. If they
say they'd find it useful *and* are willing to participate, then I
think we could make something happen. If they can't/won't participate,
I don't think this will work.
I also have concerns about the naming of a "security-discussions"
mailing list. I'm not 100% sure this use was the original intended use,
I think there were others intended. We probably need to hear from Marta
and the OE board about any other plans there.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2240):
https://lists.openembedded.org/g/openembedded-architecture/message/2240
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]]
-=-=-=-=-=-=-=-=-=-=-=-
