On Sat, 30 May 2026 at 22:30, Peter Marko via lists.openembedded.org <[email protected]> wrote: > The main problem with backporting CVEs to recipes without ptest is fact that > it's impossible to verify the patch sideeffects. > Especially for a 3-4 year old component version, where there are several > cherry-pick conflicts and some code paths are rewritten meanwhile. > Testing that CVE patch fixes a CVE is nice (assuming that exploit is at > publicly available), however testing that nothing else got broken is crucial > here. > > I certainly understand that tests can be unstable, however that can be solved > be selectively skipping single testcases. > Personally, I'd love to see all ptests being backported as the confidence on > CVE patches would be significantly boosted.
Doing 'security fixes' by backporting CVEs is a bad idea in the first place, because it means touching security critical code without any understanding of it, or having an idea whether the result is correct. Even if ptests pass, it's still very easy to get it wrong, and very difficult to verify it's correct. I continue to hold the view that the industry needs to learn to upgrade its products to actual new upstream versions. In this case, how about updating to something like wrynose, which has all the most recent ptest additions since scarthgap/kirkstone/dunfell? What exactly makes it so difficult that usually no one even wants to entertain the idea and talk about it? Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2366): https://lists.openembedded.org/g/openembedded-architecture/message/2366 Mute This Topic: https://lists.openembedded.org/mt/119437109/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
