From: Chee Yang Lee
Signed-off-by: Chee Yang Lee
---
.../virglrenderer/CVE-2022-0135.patch | 100 ++
.../virglrenderer/virglrenderer_0.8.2.bb | 1 +
2 files changed, 101 insertions(+)
create mode 100644
meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-
From: Chee Yang Lee
Signed-off-by: Chee Yang Lee
---
.../gnutls/gnutls/CVE-2021-4209.patch | 37 +++
meta/recipes-support/gnutls/gnutls_3.6.14.bb | 1 +
2 files changed, 38 insertions(+)
create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch
diff -
From: Chee Yang Lee
Signed-off-by: Chee Yang Lee
---
.../connman/connman/CVE-2022-32292.patch | 37 +++
.../connman/connman_1.37.bb | 1 +
2 files changed, 38 insertions(+)
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2022-32292.patc
On 9/11/22 7:02 AM, Steve Sakoman wrote:
Branch: master
New this week: 10 CVEs
CVE-2020-35538 (CVSS3: 5.5 MEDIUM): libjpeg-turbo:libjpeg-turbo-native
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35538 *
CVE-2022-1354 (CVSS3: 5.5 MEDIUM): tiff
https://web.nvd.nist.gov/view/vuln/det
Signed-off-by: Khem Raj
---
.../inetutils/inetutils/CVE-2022-39028.patch | 54 +++
.../inetutils/inetutils_2.3.bb| 1 +
2 files changed, 55 insertions(+)
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/CVE-2022-39028.patch
diff --git a/meta/re
They are already part of backports to 2_36 branch
as noted
Signed-off-by: Khem Raj
---
meta/recipes-devtools/binutils/binutils-2.39.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/binutils/binutils-2.39.inc
b/meta/recipes-devtools/binutils/binutils-2.39.inc
ind
Adresses CVE-2022-39046
Brings in following changeset
* c399271c10 nscd: Fix netlink cache invalidation if epoll is used [BZ #29415]
* b46412fb17 Add NEWS entry for CVE-2022-39046
* 645d94808a syslog: Remove extra whitespace between timestamp and message
(BZ#29544)
* b3736d1a3c elf: Restore how
All,
Below is the list as of top 35 bug owners as of the end of WW37 of who have
open medium or higher bugs and enhancements against YP 4.1. There are 33
possible work days left until the final release candidates for YP 4.1 needs
to be released.
Who
Count
michael.opdenac...@bootlin.com
37
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newc
From: Yi Zhao
References:
https://nvd.nist.gov/vuln/detail/CVE-2022-1354
https://security-tracker.debian.org/tracker/CVE-2022-1354
https://nvd.nist.gov/vuln/detail/CVE-2022-1355
https://security-tracker.debian.org/tracker/CVE-2022-1355
Patches from:
CVE-2022-1354:
https://gitlab.com/libtiff/li
Includes fixes for CVE-2022-3099 and CVE-2022-3134.
Signed-off-by: Richard Purdie
---
meta/recipes-support/vim/vim.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 33a82992433..70dc2dfecf5 100644
Hi Paulo
This looks very interesting. Is the goal here to just replace unfs3 on
a device running a Yocto-based firmware, or is the goal also to enable
the User Space NFS server for development without root privileges as
documented here:
https://docs.yoctoproject.org/dev-manual/qemu.html?highlight=
On Mon, Sep 12, 2022 at 11:43 AM Richard Purdie
wrote:
>
> On Sun, 2022-09-11 at 23:21 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Fri, 2022-09-09 at 23:54 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Fri, 2022-09-09 at 17:36 +0100, Ross Burton wrote:
>
On Mon, Sep 12, 2022 at 10:01 AM Marta Rybczynska wrote:
>
> On Mon, Sep 12, 2022 at 9:16 PM Steve Sakoman wrote:
> >
> > On Mon, Sep 12, 2022 at 8:57 AM Martin Jansa wrote:
> > >
> > > You mean this list?
> > > https://lists.yoctoproject.org/g/yocto-security/message/655
> >
> > Yes, I assumed e
On Mon, Sep 12, 2022 at 9:16 PM Steve Sakoman wrote:
>
> On Mon, Sep 12, 2022 at 8:57 AM Martin Jansa wrote:
> >
> > You mean this list?
> > https://lists.yoctoproject.org/g/yocto-security/message/655
>
> Yes, I assumed everyone was aware of the weekly CVE list! Did you
> have something else in
On Mon, Sep 12, 2022 at 12:08 PM Paulo Neves wrote:
>
> it should as there is no rpc code in the project as far as i scanned. I
> built it with musl successfully.
OK thanks for confirming.
>
> Paulo Neves
>
> On 9/12/22 17:06, Khem Raj wrote:
> > On Mon, Sep 12, 2022 at 2:21 AM Paulo Neves wrot
On Mon, Sep 12, 2022 at 8:57 AM Martin Jansa wrote:
>
> You mean this list?
> https://lists.yoctoproject.org/g/yocto-security/message/655
Yes, I assumed everyone was aware of the weekly CVE list! Did you
have something else in mind?
Steve
> On Mon, Sep 12, 2022 at 8:56 PM Marta Rybczynska wro
it should as there is no rpc code in the project as far as i scanned. I
built it with musl successfully.
Paulo Neves
On 9/12/22 17:06, Khem Raj wrote:
On Mon, Sep 12, 2022 at 2:21 AM Paulo Neves wrote:
watchdog code does not have any dependency on rpc code,
therefore the dependency and flags
You mean this list?
https://lists.yoctoproject.org/g/yocto-security/message/655
On Mon, Sep 12, 2022 at 8:56 PM Marta Rybczynska
wrote:
>
>
>
> On Mon, 12 Sept 2022, 17:55 Steve Sakoman, wrote:
>
>> Reply to this thread noting which CVE you plan to work on. Please
>> don't claim one unless you
On Mon, 12 Sept 2022, 17:55 Steve Sakoman, wrote:
> Reply to this thread noting which CVE you plan to work on. Please
> don't claim one unless you really intend to follow through!
>
> Hello Steve,
What about sending the list of pending CVEs (from the existing
dunfell/kirkstone/master lists) for
Reply to this thread noting which CVE you plan to work on. Please
don't claim one unless you really intend to follow through!
Thanks!
Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170539):
https://lists.openembedded.org/g/openembedded-cor
Sadly the CVE count for dunfell has been creeping up over the past
few months. Several people regularly contribute CVE patches for
dunfell and their efforts are much appreciated. But we need more
help!
To encourage more folks to contribute to this effort I'm going to be
holding a raffle from now t
On Mon, Sep 12, 2022 at 2:21 AM Paulo Neves wrote:
>
> watchdog code does not have any dependency on rpc code,
> therefore the dependency and flags to try to use it are
> removed.
>
> Signed-off-by: Paulo Neves
> ---
> meta/recipes-extended/watchdog/watchdog_5.16.bb | 4
> 1 file changed, 4
On Sun, 2022-09-11 at 16:47 +0800, kai wrote:
> From: Kai Kang
>
> It provides more binary files by binutils 2.39. Then add them to
> USE_ALTERNATIVES_FOR as others to handle symlink files via
> update-alternative mechanism.
>
> Signed-off-by: Kai Kang
> ---
> meta/recipes-devtools/binutils/bi
Hi Joel,
On 2022-09-11 03:00, Joel Winarske wrote:
I'm putting together a recipe that requires two passes, native, then
target. I'm hitting a python error only in the native pass. I can
cross compile the tool without error, so the problem is isolated to
native. Any ideas?
Recipe is progr
On Sun, 2022-09-11 at 23:21 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2022-09-09 at 23:54 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Fri, 2022-09-09 at 17:36 +0100, Ross Burton wrote:
> > > The KDE build uses custom catalogs by setting XML_CATALOG_FILES
watchdog code does not have any dependency on rpc code,
therefore the dependency and flags to try to use it are
removed.
Signed-off-by: Paulo Neves
---
meta/recipes-extended/watchdog/watchdog_5.16.bb | 4
1 file changed, 4 deletions(-)
diff --git a/meta/recipes-extended/watchdog/watchdog_5
meta-clang has options when it comes to C++ runtime, default is to use
gnu runtime, other options are llvm runtime and android runtime. This
patch helps when a distro is using llvm runtime for C/C++ runtime. It
informs the rust build system about right C++ runtime to configure for
when such a setti
The :append can not be removed via bbappends if needed. Thus it's better
for open source layers to use += append if possible.
Signed-off-by: Mikko Rapeli
---
meta/recipes-devtools/python/python3-rfc3986-validator_0.1.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/r
The :append can not be removed if needed in other layers.
Signed-off-by: Mikko Rapeli
---
meta/recipes-devtools/go/go-native_1.19.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/go/go-native_1.19.bb
b/meta/recipes-devtools/go/go-native_1.19.bb
index
The :append can not be removed via bbappends in custom layers so it's
better to use += appends when ever possible.
Signed-off-by: Mikko Rapeli
---
.../linux-libc-headers/linux-libc-headers_5.19.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kern
:append can not be modified in bbappends and thus += is
better in re-usable, generic layers and recipes.
Signed-off-by: Mikko Rapeli
---
meta/recipes-core/glibc/glibc-tests_2.36.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc-tests_2.36.bb
+= allows custom layers to change the SRC_URI e.g. when
updating the whole recipe to newer u-boot version.
With :append, there is no way to change the variable
from a bbappend.
Signed-off-by: Mikko Rapeli
---
meta/recipes-bsp/u-boot/u-boot_2022.07.bb | 2 +-
1 file changed, 1 insertion(+), 1 del
It's better to use SRC_URI += to append patches etc. If anything
is added via :append, that can no longer be removed at all.
If common, re-usable layers use SRC_URI:append, then users can
not change those patches or SRC_URI entries without completely
replacing the recipe with a copy in their own la
Using SRC_URI:append without recipe, machine or architecture
specific limitations makes the :append'ed text unremovable
and thus users and custom layers can not change the variable
anymore. This makes it hard to e.g. override SRC_URI completely
in a bbappend to update the full recipe to a newer ver
On Sun, 2022-09-11 at 16:28 -0700, Khem Raj wrote:
> meta-clang has options when it comes to C++ runtime, default is to use
> gnu runtime, other options are llvm runtime and android runtime. This
> patch helps when a distro is using llvm runtime for C/C++ runtime. It
> informs the rust build system
36 matches
Mail list logo
