Hello, Know I'm just a drive by contributor, but I agree with Tim. Think having a separate layer for just one recipe is over kill.
Would it be fine to stop applying CVE patches to vim and keep the recipe in oe-core? I and i'm assuming most people solely use it for development purposes anyways. Then remove vim from production builds. Given the package do CVE patches really matter? Vincent On Fri, May 8, 2026, 11:03 AM Tim Orling via lists.openembedded.org <[email protected]> wrote: > I understand the pain points you mention, as I have tried to help maintain > vim in oe-core. > > However, I have a LIFETIME of muscle memory using vim and for me > personally forcing me to use nano is a non starter. > So then I would be constantly needing to pull it in from wherever else it > gets moved. > > I don't have any good suggestions for how to deal with the problem, > however. > > On Fri, May 8, 2026 at 6:29 AM Paul Barker via lists.openembedded.org > <[email protected]> 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://tracker.debian.org/pkg/vim >> [2]: https://github.com/xyproto/tinyxxd >> >> Best regards, >> >> -- >> Paul Barker >> >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236730): https://lists.openembedded.org/g/openembedded-core/message/236730 Mute This Topic: https://lists.openembedded.org/mt/119215860/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
