Me too! I'm a bit frustrated with vim but resigned to updating it regularly to keep on top of the seemingly never ending list of CVEs :/. Cheers, Richard

Sean, could you check if it is your case too? I'll be adding a more verbose error message so that we know which package it comes from. Regards, Marta

<richard.purdie@...> wrote: Right, that's fine. I wish we could have a tidy list of things that need to be updated, but some components like vim don;t make it possible. Alex

The cve-check class writes temporary files to preserve state across the build, and cleans them up in a CookerExit handler. However, in memory-resident builds the cooker won't exit in between builds,

This is fixed in 2.4.2, which we have, but the complex CPE in that CVE isn't parsed by cve-check correctly so it thinks that we're vulnerable. Signed-off-by: Ross Burton <ross.burton@...> ---

Includes a fix for CVE-2022-29458 Signed-off-by: Richard Purdie <richard.purdie@...> --- meta/recipes-core/ncurses/ncurses.inc | 2 +-

From: Lee Chee Yang <lcyang92@...> Signed-off-by: Chee Yang Lee <chee.yang.lee@...> --- .../ghostscript/CVE-2022-2085.patch | 44 +++++++++++++++++++

We're definitely not doing that, it is incorrect on many different levels (e.g. fetching is not dependent on the target compiler version just for starters). You also just made all native recipes

I'm not sure it makes a lot of difference. The 5 changes after 9.0 look relatively harmless, some of them are translation fixes. This change addresses 4 CVEs and I suspect there will be more to follow

Would it be better to stay at 9.0.0000 for now? Alex

The license checksum changed due to a major version change in the referenced file. Signed-off-by: Richard Purdie <richard.purdie@...> --- .../vim/{vim-tiny_8.2.bb => vim-tiny-9.0.bb}

If we have the build with different gcc versions in the same workspace it might happen that nativesdk recipe will not detect the change of gcc and the package will be taken from sstate-cache. This

We need to add ruby-native dependency for nativesdk class too to fix the compilation issue Earlier this dependency is part of DEPENDS variable but the below commit removes it from DEPENDS and add only

Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2a4fc266dbf77ed7ab83da16468e9ba627b8bc2d] Signed-off-by: Pgowda <pgowda.cve@...> ---

Hi all, I've been working with signing packages via gpg (specificall RPM, but that shouldn't really matter) lately and things mostly work fine (modulo that small patch from some 2 weeks ago now in

Hello Richard, Yes, but variants have set SDK_EXT_TYPE=full. Can't say about the pure poky eSDK, but with our layers, size is different. Let's say 2/3 of the "working" one. Do you really need

Hi Richard, Thanks very much for pointing that out. I could reproduce the issue on the docker host that does not contain zlib-devel. Trying to analyse the issue on dependency of zlib. It would be

Commit bd36593ba3db758b3eacc974e48468a665967961 did introduce a regression when building package rust-cross-canadian-aarch64 on a x86_64 host. This commit will fix that configuration. Suggested-by:

Source: https://git.savannah.gnu.org/cgit/grub.git/ MR: 116495 Type: Security Fix Disposition: Backport from

Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2a4fc266dbf77ed7ab83da16468e9ba627b8bc2d] Signed-off-by: Pgowda <pgowda.cve@...> ---