Why not always updating to the latest version also in stable releases? It is usually used in debug images and it is mostly used interactively by a user. This will reduce the effort on backporting CVEs and we let the AUH update it.
Is there any other component that depends on it to keep backward compatibility? Daniel > -----Original Message----- > From: [email protected] > <[email protected]> On Behalf Of Tom > Rini via lists.openembedded.org > Sent: Friday, 8 May 2026 21:19 > To: Paul Barker <[email protected]> > Cc: [email protected]; openembedded- > [email protected] > Subject: Re: [Openembedded-architecture] What to do with vim in > openembedded-core? > > On Fri, May 08, 2026 at 02:29:43PM +0100, Paul Barker wrote: > > > Hi all, > > > > We have a vim recipe in openembedded-core to provide: > > - An editor without the limitations of busybox vi. > > - The `xxd` command, used as a runtime dependency of dosfstools-ptest. > > > > However, vim is difficult to maintain in our stable releases. There is > > a regular stream of CVEs that need fixing due to the large UI and > > input surface of vim, and backporting fixes has proven difficult. This > > isn't just a Yocto Project issue, the Debian tracker [1] currently > > shows 14 unresolved CVEs in Trixie and 15 unresolved CVEs in Bookworm. > > And, it's very difficult to share work between distros, as vim tags > > every commit as a new release, every distro ends up on a different > > release and needs to re-validate any backported patches. > > > > So, I propose we drop vim from openembedded-core on the master branch, > > post-wrynose. > > > > We can use tinyxxd [2] to provide xxd, this is based on the vim > > codebase and frequently merges changes from upstream. > > > > We can use GNU Nano as our default editor where something more capable > > than busybox vi is needed, this has a sensible release model. The much > > simpler input model and lack of scripting facility means that CVEs in > > nano are much fewer and further between. > > > > If we do this, what should we do with vim? We could move it back to > > meta-oe, but that would simply be moving the maintenance burden. We > > could stop backporting CVE fixes to vim and recommend that an LTS > > mixin layer is used to provide newer versions of vim for stable > > branches. I'm open to ideas. > > > > [1]: > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac > > > ker.debian.org%2Fpkg%2Fvim&data=05%7C02%7Cdaniel.turull%40ericsson.c > om > > > %7C1653ce92c13f4675f7cb08dead36aa5b%7C92e84cebfbfd47abbe52080c6b > 87953f > > > %7C0%7C0%7C639138647461125793%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGki > > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ > > > %3D%3D%7C0%7C%7C%7C&sdata=ivfBqDK0zeNVe8j%2By3%2FZqDxzC0%2BF > 6y1UakQImB > > marrA%3D&reserved=0 > > [2]: > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Fxyproto%2Ftinyxxd&data=05%7C02%7Cdaniel.turull%40ericsson.c > om > > > %7C1653ce92c13f4675f7cb08dead36aa5b%7C92e84cebfbfd47abbe52080c6b > 87953f > > > %7C0%7C0%7C639138647461144379%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGki > > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ > > > %3D%3D%7C0%7C%7C%7C&sdata=aCR%2BfMIOOrKXnP0F%2Fp1qXrjyKw%2B > NQGUn96G6%2 > > FnAYrOg%3D&reserved=0 > > Not an objection, but a note. The motivation behind bringing vim in was for > "exclude busybox, have identical functionality". Changing that to "almost > identical functionality" and pulling in nano is probably fine. > Probably just means adding another virtual which busybox provides with "vi" > and nano can also provide. > > -- > Tom
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236782): https://lists.openembedded.org/g/openembedded-core/message/236782 Mute This Topic: https://lists.openembedded.org/mt/119252867/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
