[oe-core][PATCH] gtk4: upgrade 4.12.0 -> 4.12.1
Overview of Changes in 4.12.1, 25-08-2023
=
* GtkGridView:
* Wayland:
- Fix a crash with compositors other than gnome-shell
* Translation updates:
Polish
Swedish
Signed-off-by: Markus Volk
---
meta/recipes-gnome/gtk+/{gtk4_4.12.0.bb => gtk4_4.12.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-gnome/gtk+/{gtk4_4.12.0.bb => gtk4_4.12.1.bb} (98%)
diff --git a/meta/recipes-gnome/gtk+/gtk4_4.12.0.bb
b/meta/recipes-gnome/gtk+/gtk4_4.12.1.bb
similarity index 98%
rename from meta/recipes-gnome/gtk+/gtk4_4.12.0.bb
rename to meta/recipes-gnome/gtk+/gtk4_4.12.1.bb
index 4f38e0cb2c..aa7115b11e 100644
--- a/meta/recipes-gnome/gtk+/gtk4_4.12.0.bb
+++ b/meta/recipes-gnome/gtk+/gtk4_4.12.1.bb
@@ -37,7 +37,7 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
UPSTREAM_CHECK_REGEX = "gtk-(?P\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz"
SRC_URI =
"http://ftp.gnome.org/pub/gnome/sources/gtk/${MAJ_VER}/gtk-${PV}.tar.xz;
-SRC_URI[sha256sum] =
"a6d10829f405b1afc0b65e2a9642c04126a1d1b638d11c6d97426da4f84f1f6f"
+SRC_URI[sha256sum] =
"b8b61d6cf94fac64bf3a0bfc7af137c9dd2f8360033fdeb0cfe9612b77a99a72"
S = "${WORKDIR}/gtk-${PV}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186849):
https://lists.openembedded.org/g/openembedded-core/message/186849
Mute This Topic: https://lists.openembedded.org/mt/101026055/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone][PATCH] inetutils: Fix CVE-2023-40303
Hi Khem Raj,
I have backported your patch for kirkstone and sent v2 patch for review.
https://lists.openembedded.org/g/openembedded-core/message/186847
Thanks & Regards,
Vijay
On Mon, Aug 28, 2023 at 10:42 PM Khem Raj wrote:
> I sent a patch for master already see
>
> https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_inetutils_fix/100993486?p=,,,100,0,0,0::recentpostdate/sticky,,,100,2,0,100993486,previd%3D1693242624210149855,nextid%3D1692981851065733310=1693242624210149855=1692981851065733310
>
> you can send a direct backport of that for kirkstone.
>
> On Mon, Aug 28, 2023 at 8:39 AM Vijay Anusuri via
> lists.openembedded.org
> wrote:
> >
> > From: Vijay Anusuri
> >
> > Upstream-commit:
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
> > &
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=9122999252c7e21eb7774de11d539748e7bdf46d
> >
> > Signed-off-by: Vijay Anusuri
> > ---
> > ...tpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch | 282 ++
> > ...03-Indent-changes-in-previous-commit.patch | 256
> > .../inetutils/inetutils_2.2.bb| 2 +
> > 3 files changed, 540 insertions(+)
> > create mode 100644
> meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> > create mode 100644
> meta/recipes-connectivity/inetutils/inetutils/0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch
> >
> > diff --git
> a/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> > new file mode 100644
> > index 00..0f388ec424
> > --- /dev/null
> > +++
> b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> > @@ -0,0 +1,282 @@
> > +From e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6 Mon Sep 17 00:00:00 2001
> > +From: Jeffrey Bencteux
> > +Date: Fri, 30 Jun 2023 19:02:45 +0200
> > +Subject: [PATCH] CVE-2023-40303 ftpd,rcp,rlogin,rsh,rshd,uucpd: fix:
> check set*id() return values
> > +
> > +Several setuid(), setgid(), seteuid() and setguid() return values
> > +were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
> > +leading to potential security issues.
> > +
> > +Signed-off-by: Jeffrey Bencteux
> > +Signed-off-by: Simon Josefsson
> > +
> > +Upstream-Status: Backport [
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
> ]
> > +CVE: CVE-2023-40303
> > +Signed-off-by: Vijay Anusuri
> > +---
> > + ftpd/ftpd.c | 10 +++---
> > + src/rcp.c| 39 +--
> > + src/rlogin.c | 11 +--
> > + src/rsh.c| 25 +
> > + src/rshd.c | 20 +---
> > + src/uucpd.c | 15 +--
> > + 6 files changed, 100 insertions(+), 20 deletions(-)
> > +
> > +diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
> > +index 68d41fd..703fbbc 100644
> > +--- a/ftpd/ftpd.c
> > b/ftpd/ftpd.c
> > +@@ -865,7 +865,9 @@ end_login (struct credentials *pcred)
> > + char *remotehost = pcred->remotehost;
> > + int atype = pcred->auth_type;
> > +
> > +- seteuid ((uid_t) 0);
> > ++ if (seteuid ((uid_t) 0) == -1)
> > ++_exit (EXIT_FAILURE);
> > ++
> > + if (pcred->logged_in)
> > + {
> > + logwtmp_keep_open (ttyline, "", "");
> > +@@ -1154,7 +1156,8 @@ getdatasock (const char *mode)
> > +
> > + if (data >= 0)
> > + return fdopen (data, mode);
> > +- seteuid ((uid_t) 0);
> > ++ if (seteuid ((uid_t) 0) == -1)
> > ++_exit (EXIT_FAILURE);
> > + s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
> > + if (s < 0)
> > + goto bad;
> > +@@ -1981,7 +1984,8 @@ passive (int epsv, int af)
> > + else/* !AF_INET6 */
> > + ((struct sockaddr_in *) _addr)->sin_port = 0;
> > +
> > +- seteuid ((uid_t) 0);
> > ++ if (seteuid ((uid_t) 0) == -1)
> > ++_exit (EXIT_FAILURE);
> > + if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
> > + {
> > + if (seteuid ((uid_t) cred.uid))
> > +diff --git a/src/rcp.c b/src/rcp.c
> > +index 476cbaa..cd84570 100644
> > +--- a/src/rcp.c
> > b/src/rcp.c
> > +@@ -348,14 +348,23 @@ main (int argc, char *argv[])
> > + if (from_option)
> > + { /* Follow "protocol", send data. */
> > + response ();
> > +- setuid (userid);
> > ++
> > ++ if (setuid (userid) == -1)
> > ++ {
> > ++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
> failed)");
> > ++ }
> > ++
> > + source (argc, argv);
> > + exit (errs);
> > + }
> > +
> > + if (to_option)
> > + { /* Receive data. */
> > +- setuid (userid);
> > ++ if (setuid (userid) == -1)
> > ++ {
> > ++error (EXIT_FAILURE, 0, "Could not
[OE-core][kirkstone][PATCH v2] inetutils: Backport fix for CVE-2023-40303
From: Vijay Anusuri
Upstream-commit:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
&
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=9122999252c7e21eb7774de11d539748e7bdf46d
Signed-off-by: Vijay Anusuri
---
...tpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch | 280 ++
...03-Indent-changes-in-previous-commit.patch | 254
.../inetutils/inetutils_2.2.bb| 2 +
3 files changed, 536 insertions(+)
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch
diff --git
a/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
new file mode 100644
index 00..7f5baf3637
--- /dev/null
+++
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
@@ -0,0 +1,280 @@
+From 703418fe9d2e3b1e8d594df5788d8001a8116265 Mon Sep 17 00:00:00 2001
+From: Jeffrey Bencteux
+Date: Fri, 30 Jun 2023 19:02:45 +0200
+Subject: [PATCH] CVE-2023-40303: ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check
+ set*id() return values
+
+Several setuid(), setgid(), seteuid() and setguid() return values
+were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
+leading to potential security issues.
+
+CVE: CVE-2023-40303
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6]
+Signed-off-by: Jeffrey Bencteux
+Signed-off-by: Simon Josefsson
+Signed-off-by: Khem Raj
+Signed-off-by: Vijay Anusuri
+---
+ ftpd/ftpd.c | 10 +++---
+ src/rcp.c| 39 +--
+ src/rlogin.c | 11 +--
+ src/rsh.c| 25 +
+ src/rshd.c | 20 +---
+ src/uucpd.c | 15 +--
+ 6 files changed, 100 insertions(+), 20 deletions(-)
+
+diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
+index 92b2cca5..28dd523f 100644
+--- a/ftpd/ftpd.c
b/ftpd/ftpd.c
+@@ -862,7 +862,9 @@ end_login (struct credentials *pcred)
+ char *remotehost = pcred->remotehost;
+ int atype = pcred->auth_type;
+
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
++
+ if (pcred->logged_in)
+ {
+ logwtmp_keep_open (ttyline, "", "");
+@@ -1151,7 +1153,8 @@ getdatasock (const char *mode)
+
+ if (data >= 0)
+ return fdopen (data, mode);
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+ s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
+ if (s < 0)
+ goto bad;
+@@ -1978,7 +1981,8 @@ passive (int epsv, int af)
+ else/* !AF_INET6 */
+ ((struct sockaddr_in *) _addr)->sin_port = 0;
+
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+ if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
+ {
+ if (seteuid ((uid_t) cred.uid))
+diff --git a/src/rcp.c b/src/rcp.c
+index 75adb253..cdcf8500 100644
+--- a/src/rcp.c
b/src/rcp.c
+@@ -345,14 +345,23 @@ main (int argc, char *argv[])
+ if (from_option)
+ { /* Follow "protocol", send data. */
+ response ();
+- setuid (userid);
++
++ if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
++
+ source (argc, argv);
+ exit (errs);
+ }
+
+ if (to_option)
+ { /* Receive data. */
+- setuid (userid);
++ if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
++
+ sink (argc, argv);
+ exit (errs);
+ }
+@@ -537,7 +546,11 @@ toremote (char *targ, int argc, char *argv[])
+ if (response () < 0)
+ exit (EXIT_FAILURE);
+ free (bp);
+-setuid (userid);
++
++if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
+ }
+ source (1, argv + i);
+ close (rem);
+@@ -630,7 +643,12 @@ tolocal (int argc, char *argv[])
+ ++errs;
+ continue;
+ }
+- seteuid (userid);
++
++ if (seteuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (seteuid()
failed)");
++ }
++
+ #if defined IP_TOS && defined IPPROTO_IP && defined IPTOS_THROUGHPUT
+ sslen = sizeof (ss);
+ (void) getpeername (rem, (struct sockaddr *) , );
+@@ -643,7 +661,12 @@ tolocal (int argc, char *argv[])
+ #endif
+ vect[0] = target;
+
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On 8/28/23 14:45, Randolph Sapp wrote:
On 8/28/23 11:22, Randolph Sapp wrote:
On 8/28/23 10:09, Max Krummenacher wrote:
On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
lists.openembedded.org
wrote:
On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
wrote:
-Original Message-
From: Max Krummenacher
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
Cc: Max Krummenacher ; Randolph Sapp
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass:
Inhibit the
default dependencies"
From: Max Krummenacher
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package
ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no
providers found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package
ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package
ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no
providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
From the bugzilla entry [1] which added the feature and from the
commit
adding the class [2] it looks to me that the class should simplify
adding
binaries externally built for the target.
Having the users of the class having to add the used libc / compiler
shared objects to not trigger a qa warning seems really wrong to me.
Additionally I don't see the advantage in not installing the base
dependencies. Doing anything usefull in a build would need to build
them anyway for some other recipe, so one would save creating a few
hard links. Do I miss something here?
So IMHO a recipe which inherits the class and really does not like the
default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Adding the missing links, sorry about that:
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
[2]
https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
Thanks for bringing this to light Max. I have no opinion in this. I
understand not wanting to implicitly depending on anything. After all,
explicit is always nice for those that don't want to navigate the full
include chain to figure out recipe dependencies. It's also nicer for a
minimal build (though arguably not in this case because these are core
packages we're depending on).
If this is going to be the standard moving forward please let me know
so I can update this recipe accordingly.
Scratch that, I have an opinion now. Removing hidden base package
dependencies that QA steps explicitly rely is a bad idea. Please revert
this.
Or at least have the insane.bbclass class introduce it's required
dependencies itself, as that seems more logical than having a generic
base group anyway.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186846):
https://lists.openembedded.org/g/openembedded-core/message/186846
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On 8/28/23 11:22, Randolph Sapp wrote:
On 8/28/23 10:09, Max Krummenacher wrote:
On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
lists.openembedded.org
wrote:
On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
wrote:
-Original Message-
From: Max Krummenacher
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
Cc: Max Krummenacher ; Randolph Sapp
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass:
Inhibit the
default dependencies"
From: Max Krummenacher
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package
ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers
found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package
ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package
ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no
providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
From the bugzilla entry [1] which added the feature and from the commit
adding the class [2] it looks to me that the class should simplify
adding
binaries externally built for the target.
Having the users of the class having to add the used libc / compiler
shared objects to not trigger a qa warning seems really wrong to me.
Additionally I don't see the advantage in not installing the base
dependencies. Doing anything usefull in a build would need to build
them anyway for some other recipe, so one would save creating a few
hard links. Do I miss something here?
So IMHO a recipe which inherits the class and really does not like the
default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Adding the missing links, sorry about that:
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
[2]
https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
Thanks for bringing this to light Max. I have no opinion in this. I
understand not wanting to implicitly depending on anything. After all,
explicit is always nice for those that don't want to navigate the full
include chain to figure out recipe dependencies. It's also nicer for a
minimal build (though arguably not in this case because these are core
packages we're depending on).
If this is going to be the standard moving forward please let me know so
I can update this recipe accordingly.
Scratch that, I have an opinion now. Removing hidden base package
dependencies that QA steps explicitly rely is a bad idea. Please revert
this.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186845):
https://lists.openembedded.org/g/openembedded-core/message/186845
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH] volatile-binds: Calculate the name of the /var/lib service
Thanks, I submitted a v2 patch with the corrections you suggested. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186844): https://lists.openembedded.org/g/openembedded-core/message/186844 Mute This Topic: https://lists.openembedded.org/mt/100993882/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH v2] volatile-binds: Calculate the name of the /var/lib service
By default, /var/lib is bind mounted on /var/volatile/lib. If this is
the case, the recipe adds conditions on systemd-random-seed in the
service file mounting it. But as the VOLATILE_BINDS may be modified,
/var/lib may be mounted elsewhere, for example in /persistent/var/lib.
In this case, the conditions are not set because the service file name
does not match expected one.
This patch automatically records the name of the service mounting
/var/lib, if any, in order to set the condition in the appropriate file.
Signed-off-by: Stéphane Veyret
---
.../volatile-binds/volatile-binds.bb | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index 3fefa9abde..cca8a65fb4 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -16,10 +16,10 @@ inherit allarch systemd features_check
REQUIRED_DISTRO_FEATURES = "systemd"
VOLATILE_BINDS ?= "\
-/var/volatile/lib /var/lib\n\
-/var/volatile/cache /var/cache\n\
-/var/volatile/spool /var/spool\n\
-/var/volatile/srv /srv\n\
+${localstatedir}/volatile/lib ${localstatedir}/lib\n\
+${localstatedir}/volatile/cache ${localstatedir}/cache\n\
+${localstatedir}/volatile/spool ${localstatedir}/spool\n\
+${localstatedir}/volatile/srv /srv\n\
"
VOLATILE_BINDS[type] = "list"
VOLATILE_BINDS[separator] = "\n"
@@ -46,8 +46,8 @@ do_compile () {
continue
fi
-servicefile="${spec#/}"
-servicefile="$(echo "$servicefile" | tr / -).service"
+servicefile="$(echo "${spec#/}" | tr / -).service"
+[ "$mountpoint" != ${localstatedir}/lib ] ||
var_lib_servicefile=$servicefile
sed -e "s#@what@#$spec#g; s#@where@#$mountpoint#g" \
-e "s#@whatparent@#${spec%/*}#g;
s#@whereparent@#${mountpoint%/*}#g" \
-e "s#@avoid_overlayfs@#${@d.getVar('AVOID_OVERLAYFS')}#g" \
@@ -56,12 +56,12 @@ do_compile () {
${@d.getVar('VOLATILE_BINDS').replace("\\n", "\n")}
END
-if [ -e var-volatile-lib.service ]; then
+if [ -e "$var_lib_servicefile" ]; then
# As the seed is stored under /var/lib, ensure that this service runs
# after the volatile /var/lib is mounted.
sed -i -e "/^Before=/s/\$/ systemd-random-seed.service/" \
-e "/^WantedBy=/s/\$/ systemd-random-seed.service/" \
- var-volatile-lib.service
+ "$var_lib_servicefile"
fi
}
do_compile[dirs] = "${WORKDIR}"
@@ -78,7 +78,7 @@ do_install () {
# Suppress attempts to process some tmpfiles that are not temporary.
#
-install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
+install -d ${D}${sysconfdir}/tmpfiles.d ${D}${localstatedir}/cache
ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf
}
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186843):
https://lists.openembedded.org/g/openembedded-core/message/186843
Mute This Topic: https://lists.openembedded.org/mt/101015300/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 1/5] classes: jobserver: support gnu make fifo jobserver
Aug 28, 2023 14:48:46 Martin Hundebøll :
> Add a class to implement the gnu make fifo style jobserver. The class
> can be activated by symply adding an `INHERIT += "jobserver"` to the
> local configuration.
>
> Furthermore, one can configure an external jobserver (i.e. a server
> shared between multiple builds), by configured the `JOBSERVER_FIFO`
> variable to point at an existing jobserver fifo.
>
> The jobserver class uses the fifo style jobserver, which doesn't require
> passing open file descriptors around. It does, however, require
> make-4.4, which isn't available in common distro yet. To work around
> this, the class make all recipes (except make and its dependencies
> itself) depend on `virtual/make-native`.
>
> Signed-off-by: Martin Hundebøll
> ---
> meta/classes-global/jobserver.bbclass | 80 +++
> meta/conf/bitbake.conf | 2 +-
> 2 files changed, 81 insertions(+), 1 deletion(-)
> create mode 100644 meta/classes-global/jobserver.bbclass
>
> diff --git a/meta/classes-global/jobserver.bbclass
> b/meta/classes-global/jobserver.bbclass
> new file mode 100644
> index 00..c76909fe50
> --- /dev/null
> +++ b/meta/classes-global/jobserver.bbclass
> @@ -0,0 +1,80 @@
> +JOBSERVER_FIFO ?= ""
> +JOBSERVER_FIFO[doc] = "Path to external jobserver fifo to use instead of
> creating a per-build server."
> +
> +addhandler jobserver_setup_fifo
> +jobserver_setup_fifo[eventmask] = "bb.event.ConfigParsed"
> +
> +python jobserver_setup_fifo() {
> + # don't setup a per-build fifo, if an external one is configured
> + if d.getVar("JOBSERVER_FIFO"):
> + return
> +
> + # don't use a job-server if no parallelism is configured
> + jobs = oe.utils.parallel_make(d)
> + if jobs in (None, 1):
> + return
> +
> + # reduce jobs by one as a token has implicitly been handed to the
> + # process requesting tokens
> + jobs -= 1
> +
> + fifo = d.getVar("TMPDIR") + "/jobserver_fifo"
> +
> + # and old fifo might be lingering; remove it
> + if os.path.exists(fifo):
> + os.remove(fifo)
> +
> + # create a new fifo to use for communicating tokens
> + os.mkfifo(fifo)
> +
> + # fill the fifo with the number of tokens to hand out
> + wfd = os.open(fifo, os.O_RDWR)
> + written = os.write(wfd, b"+" * jobs)
> + if written != (jobs):
> + bb.error("Failed to fil make fifo: {} != {}".format(written, jobs))
> +
> + # configure the per-build fifo path to use
> + d.setVar("JOBSERVER_FIFO", fifo)
> +}
> +
> +python () {
> + # don't configure the fifo if none is defined
> + fifo = d.getVar("JOBSERVER_FIFO")
> + if not fifo:
> + return
> +
> + # avoid making make-native or its dependencies depend on make-native
> itself
> + if d.getVar("PN") in (
> + "make-native",
> + "libtool-native",
> + "pkgconfig-native",
> + "automake-native",
> + "autoconf-native",
> + "m4-native",
> + "texinfo-dummy-native",
> + "gettext-minimal-native",
> + "quilt-native",
> + "gnu-config-native",
> + ):
> + return
> +
> + # don't make unwilling recipes depend on make-native
> + if d.getVar('INHIBIT_DEFAULT_DEPS', False):
> + return
> +
> + # make other recipes depend on make-native to make sure it is new enough
> to
> + # support the --jobserver-auth=fifo: syntax (from make-4.4 and
> onwards)
> + d.appendVar("DEPENDS", " virtual/make-native")
I would like some feedback on this part, i.e. changing package dependencies
depending on a pure build-configuration like this. I would prefer if the build
didn't change at all when enabling the jobserver class, which would require
adding virtual/make-native to the base dependencies regardless of this class.
Would that be acceptable?
> + # disable the "-j " flag, as that overrides the jobserver fifo
> tokens
> + d.setVar("PARALLEL_MAKE", "")
> + d.setVar("PARALLEL_MAKEINST", "")
> +
> + # set and export the jobserver in the environment
> + d.appendVar("MAKEFLAGS", " --jobserver-auth=fifo:" + fifo)
> + d.setVarFlag("MAKEFLAGS", "export", "1")
> +
> + # ignore the joberserver argument part of MAKEFLAGS in the hash, as that
> + # shouldn't change the build output
> + d.appendVarFlag("MAKEFLAGS", "vardepvalueexclude", "|
> --jobserver-auth=fifo:" + fifo)
> +}
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index cf7ff3328c..8cf188270b 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -946,7 +946,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD
> BB_TASKHASH BBPATH BBSERVER DL_DI
> BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot
> DEPLOY_DIR \
> SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \
> SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE
> GIT_CEILING_DIRECTORIES \
> -
Re: [OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
Aug 28, 2023 19:16:28 Khem Raj :
> On Mon, Aug 28, 2023 at 5:48 AM Martin Hundeb?ll wrote:
>>
>> Ninja doesn't (yet) support the GNU Make jobserver out of the box, but
>> there is a pull request adding that support[1]. Switch the SRC_URI and
>> SRCREV to point at the source of that pull request, to make ninja play
>> nicely together with the recently added jobserver class.
>>
>> Signed-off-by: Martin Hundebøll
>> ---
>> .../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} (84%)
>>
>> diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
>> b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
>> similarity index 84%
>> rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
>> rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
>> index 8e297ec4d4..9abdd40a92 100644
>> --- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
>> +++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
>> @@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
>> "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
>>
>> DEPENDS = "re2c-native ninja-native"
>>
>> -SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
>> +SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
>>
>> -SRC_URI =
>> "git://github.com/ninja-build/ninja.git;branch=release;protocol=https"
>> +SRC_URI =
>> "git://github.com/stefanb2/ninja.git;branch=topic-issue-1139-part-3-jobserver-fifo;protocol=https"
>
> This is a little concerning, as we are pointing to a fork here and
> quite a lot depend on ninja now
> a days. so I wonder whats the status of the patches and likelyhood of
> them going upstream
> in anycase, we should pick the patches instead of switching SRC_URI
Yes, I agree that we shouldn't change uri to a fork; hence the RFC... Maybe I
should try to put some pressure on ninja upstream to consider the pull
request...
I can look into whether a separate patch is feasible...
>> UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
>>
>> S = "${WORKDIR}/git"
>> --
>> 2.41.0
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186841):
https://lists.openembedded.org/g/openembedded-core/message/186841
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
On Mon, Aug 28, 2023 at 5:48 AM Martin Hundeb?ll wrote:
>
> Ninja doesn't (yet) support the GNU Make jobserver out of the box, but
> there is a pull request adding that support[1]. Switch the SRC_URI and
> SRCREV to point at the source of that pull request, to make ninja play
> nicely together with the recently added jobserver class.
>
> Signed-off-by: Martin Hundebøll
> ---
> .../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb}| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} (84%)
>
> diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> similarity index 84%
> rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
> rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
> index 8e297ec4d4..9abdd40a92 100644
> --- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> +++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> @@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
>
> DEPENDS = "re2c-native ninja-native"
>
> -SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
> +SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
>
> -SRC_URI =
> "git://github.com/ninja-build/ninja.git;branch=release;protocol=https"
> +SRC_URI =
> "git://github.com/stefanb2/ninja.git;branch=topic-issue-1139-part-3-jobserver-fifo;protocol=https"
This is a little concerning, as we are pointing to a fork here and
quite a lot depend on ninja now
a days. so I wonder whats the status of the patches and likelyhood of
them going upstream
in anycase, we should pick the patches instead of switching SRC_URI
> UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
>
> S = "${WORKDIR}/git"
> --
> 2.41.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186840):
https://lists.openembedded.org/g/openembedded-core/message/186840
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone][PATCH] inetutils: Fix CVE-2023-40303
I sent a patch for master already see
https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_inetutils_fix/100993486?p=,,,100,0,0,0::recentpostdate/sticky,,,100,2,0,100993486,previd%3D1693242624210149855,nextid%3D1692981851065733310=1693242624210149855=1692981851065733310
you can send a direct backport of that for kirkstone.
On Mon, Aug 28, 2023 at 8:39 AM Vijay Anusuri via
lists.openembedded.org
wrote:
>
> From: Vijay Anusuri
>
> Upstream-commit:
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
> &
> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=9122999252c7e21eb7774de11d539748e7bdf46d
>
> Signed-off-by: Vijay Anusuri
> ---
> ...tpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch | 282 ++
> ...03-Indent-changes-in-previous-commit.patch | 256
> .../inetutils/inetutils_2.2.bb| 2 +
> 3 files changed, 540 insertions(+)
> create mode 100644
> meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> create mode 100644
> meta/recipes-connectivity/inetutils/inetutils/0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch
>
> diff --git
> a/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
>
> b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> new file mode 100644
> index 00..0f388ec424
> --- /dev/null
> +++
> b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
> @@ -0,0 +1,282 @@
> +From e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6 Mon Sep 17 00:00:00 2001
> +From: Jeffrey Bencteux
> +Date: Fri, 30 Jun 2023 19:02:45 +0200
> +Subject: [PATCH] CVE-2023-40303 ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check
> set*id() return values
> +
> +Several setuid(), setgid(), seteuid() and setguid() return values
> +were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
> +leading to potential security issues.
> +
> +Signed-off-by: Jeffrey Bencteux
> +Signed-off-by: Simon Josefsson
> +
> +Upstream-Status: Backport
> [https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6]
> +CVE: CVE-2023-40303
> +Signed-off-by: Vijay Anusuri
> +---
> + ftpd/ftpd.c | 10 +++---
> + src/rcp.c| 39 +--
> + src/rlogin.c | 11 +--
> + src/rsh.c| 25 +
> + src/rshd.c | 20 +---
> + src/uucpd.c | 15 +--
> + 6 files changed, 100 insertions(+), 20 deletions(-)
> +
> +diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
> +index 68d41fd..703fbbc 100644
> +--- a/ftpd/ftpd.c
> b/ftpd/ftpd.c
> +@@ -865,7 +865,9 @@ end_login (struct credentials *pcred)
> + char *remotehost = pcred->remotehost;
> + int atype = pcred->auth_type;
> +
> +- seteuid ((uid_t) 0);
> ++ if (seteuid ((uid_t) 0) == -1)
> ++_exit (EXIT_FAILURE);
> ++
> + if (pcred->logged_in)
> + {
> + logwtmp_keep_open (ttyline, "", "");
> +@@ -1154,7 +1156,8 @@ getdatasock (const char *mode)
> +
> + if (data >= 0)
> + return fdopen (data, mode);
> +- seteuid ((uid_t) 0);
> ++ if (seteuid ((uid_t) 0) == -1)
> ++_exit (EXIT_FAILURE);
> + s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
> + if (s < 0)
> + goto bad;
> +@@ -1981,7 +1984,8 @@ passive (int epsv, int af)
> + else/* !AF_INET6 */
> + ((struct sockaddr_in *) _addr)->sin_port = 0;
> +
> +- seteuid ((uid_t) 0);
> ++ if (seteuid ((uid_t) 0) == -1)
> ++_exit (EXIT_FAILURE);
> + if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
> + {
> + if (seteuid ((uid_t) cred.uid))
> +diff --git a/src/rcp.c b/src/rcp.c
> +index 476cbaa..cd84570 100644
> +--- a/src/rcp.c
> b/src/rcp.c
> +@@ -348,14 +348,23 @@ main (int argc, char *argv[])
> + if (from_option)
> + { /* Follow "protocol", send data. */
> + response ();
> +- setuid (userid);
> ++
> ++ if (setuid (userid) == -1)
> ++ {
> ++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
> failed)");
> ++ }
> ++
> + source (argc, argv);
> + exit (errs);
> + }
> +
> + if (to_option)
> + { /* Receive data. */
> +- setuid (userid);
> ++ if (setuid (userid) == -1)
> ++ {
> ++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
> failed)");
> ++ }
> ++
> + sink (argc, argv);
> + exit (errs);
> + }
> +@@ -540,7 +549,11 @@ toremote (char *targ, int argc, char *argv[])
> + if (response () < 0)
> + exit (EXIT_FAILURE);
> + free (bp);
> +-setuid (userid);
> ++
> ++if (setuid (userid) == -1)
> ++ {
> ++error (EXIT_FAILURE, 0, "Could not
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On 8/27/2023 4:23 PM, Peter Kjellerstedt wrote:
-Original Message-
From: Max Krummenacher
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
Cc: Max Krummenacher ; Randolph Sapp
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
default dependencies"
From: Max Krummenacher
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
Was there some issue that your patch was seeking to solve? There was
not much explanation in your patch or discussion about it on the mailing
list before it was accepted.
Or did this just seem like something to do since this class doesn't
build anything?
Just looking for background.
Your commit is also the source of another error with this the same
ti-img-rogue-umlibs recipe that I've been trying to track down all last
week. Max just beat me to finding it.
I'm voting to revert your patch unless there is compelling reason for
your patch.
Max
Max Krummenacher (1):
Revert "bin_package.bbclass: Inhibit the default dependencies"
meta/classes-recipe/bin_package.bbclass | 3 ---
1 file changed, 3 deletions(-)
--
2.35.3
//Peter
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186838):
https://lists.openembedded.org/g/openembedded-core/message/186838
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On 8/28/23 10:09, Max Krummenacher wrote:
On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
lists.openembedded.org
wrote:
On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
wrote:
-Original Message-
From: Max Krummenacher
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
Cc: Max Krummenacher ; Randolph Sapp
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
default dependencies"
From: Max Krummenacher
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
From the bugzilla entry [1] which added the feature and from the commit
adding the class [2] it looks to me that the class should simplify adding
binaries externally built for the target.
Having the users of the class having to add the used libc / compiler
shared objects to not trigger a qa warning seems really wrong to me.
Additionally I don't see the advantage in not installing the base
dependencies. Doing anything usefull in a build would need to build
them anyway for some other recipe, so one would save creating a few
hard links. Do I miss something here?
So IMHO a recipe which inherits the class and really does not like the
default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Adding the missing links, sorry about that:
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
[2]
https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
Thanks for bringing this to light Max. I have no opinion in this. I
understand not wanting to implicitly depending on anything. After all,
explicit is always nice for those that don't want to navigate the full
include chain to figure out recipe dependencies. It's also nicer for a
minimal build (though arguably not in this case because these are core
packages we're depending on).
If this is going to be the standard moving forward please let me know so
I can update this recipe accordingly.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186837):
https://lists.openembedded.org/g/openembedded-core/message/186837
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libtraceevent: build with Meson
Hello, On Sun, 27 Aug 2023 20:57:44 +0100 "Ross Burton" wrote: > From: Ross Burton > > After what I presume is the recent kernel upgrade, perf started to fail > to configure. This was actually due to libtraceevent racing during its > build and failing to put one of the .o files into the .so (reminder: > Make is terrible). This doesn't cause the libtraceevent build to fail so > once the broken .so is in sstate, it causes all future perf builds to > fail. > > Instead of rewriting the Makefile rules to fix this race it's easier to > switch to Meson which doesn't have this sort of problem. However the > Meson support is pretty new and has some rough edges, so we need a patch > to make it do the right thing. > > I will submit the libtraceevent fixes upstream shortly. > > [ YOCTO #15201 ] > > Signed-off-by: Ross Burton The build I had run and that had been consistently failing has succeeded after applying this patch! Tested-by: Luca Ceresoli -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186836): https://lists.openembedded.org/g/openembedded-core/message/186836 Mute This Topic: https://lists.openembedded.org/mt/100996987/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone][PATCH] efivar: backport 5 patches to fix build with gold
On Mon, Aug 28, 2023 at 4:38 AM Martin Jansa wrote: > > On Mon, Jul 31, 2023 at 10:30 PM Martin Jansa via lists.openembedded.org > wrote: >> >> * LDFLAGS += "-fuse-ld=bfd" in the recipe doesn't work and >> it still fails to build with ld-is-gold in DISTRO_FEATURES >> >> removal of this line sent to master in: >> https://lists.openembedded.org/g/openembedded-core/message/185167 >> >> * the most important ones are the 1st which removes --add-needed >> and the last which removes src/include/workarounds.mk completely >> while 2-4 patches just update src/include/workarounds.mk for the >> last one to apply cleanly >> >> * alternatively we can bump SRCREV to latest 38 as master did in: >> >> https://git.openembedded.org/openembedded-core/commit/?id=4df808c616f847d90203582fd950a49bb8360dd0 >> which brings 23 commits, but instead of adding 5 more patches >> allows to remove 5 > > > Steve: this should be OK to backport, unless you want me to send backport of > above minor upgrade instead. Thanks Martin! I took this patch into my test queue. Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186835): https://lists.openembedded.org/g/openembedded-core/message/186835 Mute This Topic: https://lists.openembedded.org/mt/100470272/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] inetutils: Fix CVE-2023-40303
From: Vijay Anusuri
Upstream-commit:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
&
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=9122999252c7e21eb7774de11d539748e7bdf46d
Signed-off-by: Vijay Anusuri
---
...tpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch | 282 ++
...03-Indent-changes-in-previous-commit.patch | 256
.../inetutils/inetutils_2.2.bb| 2 +
3 files changed, 540 insertions(+)
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch
diff --git
a/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
new file mode 100644
index 00..0f388ec424
--- /dev/null
+++
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
@@ -0,0 +1,282 @@
+From e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6 Mon Sep 17 00:00:00 2001
+From: Jeffrey Bencteux
+Date: Fri, 30 Jun 2023 19:02:45 +0200
+Subject: [PATCH] CVE-2023-40303 ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check
set*id() return values
+
+Several setuid(), setgid(), seteuid() and setguid() return values
+were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
+leading to potential security issues.
+
+Signed-off-by: Jeffrey Bencteux
+Signed-off-by: Simon Josefsson
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6]
+CVE: CVE-2023-40303
+Signed-off-by: Vijay Anusuri
+---
+ ftpd/ftpd.c | 10 +++---
+ src/rcp.c| 39 +--
+ src/rlogin.c | 11 +--
+ src/rsh.c| 25 +
+ src/rshd.c | 20 +---
+ src/uucpd.c | 15 +--
+ 6 files changed, 100 insertions(+), 20 deletions(-)
+
+diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
+index 68d41fd..703fbbc 100644
+--- a/ftpd/ftpd.c
b/ftpd/ftpd.c
+@@ -865,7 +865,9 @@ end_login (struct credentials *pcred)
+ char *remotehost = pcred->remotehost;
+ int atype = pcred->auth_type;
+
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
++
+ if (pcred->logged_in)
+ {
+ logwtmp_keep_open (ttyline, "", "");
+@@ -1154,7 +1156,8 @@ getdatasock (const char *mode)
+
+ if (data >= 0)
+ return fdopen (data, mode);
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+ s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
+ if (s < 0)
+ goto bad;
+@@ -1981,7 +1984,8 @@ passive (int epsv, int af)
+ else/* !AF_INET6 */
+ ((struct sockaddr_in *) _addr)->sin_port = 0;
+
+- seteuid ((uid_t) 0);
++ if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+ if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
+ {
+ if (seteuid ((uid_t) cred.uid))
+diff --git a/src/rcp.c b/src/rcp.c
+index 476cbaa..cd84570 100644
+--- a/src/rcp.c
b/src/rcp.c
+@@ -348,14 +348,23 @@ main (int argc, char *argv[])
+ if (from_option)
+ { /* Follow "protocol", send data. */
+ response ();
+- setuid (userid);
++
++ if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
++
+ source (argc, argv);
+ exit (errs);
+ }
+
+ if (to_option)
+ { /* Receive data. */
+- setuid (userid);
++ if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
++
+ sink (argc, argv);
+ exit (errs);
+ }
+@@ -540,7 +549,11 @@ toremote (char *targ, int argc, char *argv[])
+ if (response () < 0)
+ exit (EXIT_FAILURE);
+ free (bp);
+-setuid (userid);
++
++if (setuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid()
failed)");
++ }
+ }
+ source (1, argv + i);
+ close (rem);
+@@ -633,7 +646,12 @@ tolocal (int argc, char *argv[])
+ ++errs;
+ continue;
+ }
+- seteuid (userid);
++
++ if (seteuid (userid) == -1)
++ {
++error (EXIT_FAILURE, 0, "Could not drop privileges (seteuid()
failed)");
++ }
++
+ #if defined IP_TOS && defined IPPROTO_IP && defined IPTOS_THROUGHPUT
+ sslen = sizeof (ss);
+ (void) getpeername (rem, (struct sockaddr *) , );
+@@ -646,7 +664,12 @@ tolocal (int argc, char *argv[])
+ #endif
+ vect[0] = target;
+ sink (1, vect);
+-
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
lists.openembedded.org
wrote:
>
> On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
> wrote:
> >
> > > -Original Message-
> > > From: Max Krummenacher
> > > Sent: den 27 augusti 2023 10:10
> > > To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
> > >
> > > Cc: Max Krummenacher ; Randolph Sapp
> > >
> > > Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
> > > default dependencies"
> > >
> > > From: Max Krummenacher
> > >
> > > Hi
> > >
> > > With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
> > > dependencies") applied I'm getting a lot of these errors, i.e. qa
> > > does miss libc and compiler provided libs:
> > >
> > > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > > /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> > > requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
> > > in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> > > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > > /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> > > requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
> > > RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> > > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > > /usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
> > > umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
> > > found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> > >
> > > Reverting the commit makes the build pass, alternatively adding
> > > to depends in the recipe which is using the bin_package class
> > > fixes it too:
> > >
> > > DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
> > >
> > > I'd prefer reverting removing the default dependencies over fixing
> > > each of the recipes which do use the bin_package class to actually
> > > install binaries running in the target user space.
> > >
> > > Any opinions?
> >
> > Bummer. I guess we will have to update our recipes individually
> > instead. :(
> >
> > >
> > > Max
> > >
> > > Max Krummenacher (1):
> > > Revert "bin_package.bbclass: Inhibit the default dependencies"
> > >
> > > meta/classes-recipe/bin_package.bbclass | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > --
> > > 2.35.3
> >
> > //Peter
> >
>
> From the bugzilla entry [1] which added the feature and from the commit
> adding the class [2] it looks to me that the class should simplify adding
> binaries externally built for the target.
> Having the users of the class having to add the used libc / compiler
> shared objects to not trigger a qa warning seems really wrong to me.
>
> Additionally I don't see the advantage in not installing the base
> dependencies. Doing anything usefull in a build would need to build
> them anyway for some other recipe, so one would save creating a few
> hard links. Do I miss something here?
>
> So IMHO a recipe which inherits the class and really does not like the
> default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Adding the missing links, sorry about that:
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
[2]
https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
>
> Regards
> Max
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186833):
https://lists.openembedded.org/g/openembedded-core/message/186833
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: Max Krummenacher
> > Sent: den 27 augusti 2023 10:10
> > To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
> >
> > Cc: Max Krummenacher ; Randolph Sapp
> >
> > Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
> > default dependencies"
> >
> > From: Max Krummenacher
> >
> > Hi
> >
> > With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
> > dependencies") applied I'm getting a lot of these errors, i.e. qa
> > does miss libc and compiler provided libs:
> >
> > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> > requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
> > in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> > requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
> > RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> > ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> > /usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
> > umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
> > found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> >
> > Reverting the commit makes the build pass, alternatively adding
> > to depends in the recipe which is using the bin_package class
> > fixes it too:
> >
> > DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
> >
> > I'd prefer reverting removing the default dependencies over fixing
> > each of the recipes which do use the bin_package class to actually
> > install binaries running in the target user space.
> >
> > Any opinions?
>
> Bummer. I guess we will have to update our recipes individually
> instead. :(
>
> >
> > Max
> >
> > Max Krummenacher (1):
> > Revert "bin_package.bbclass: Inhibit the default dependencies"
> >
> > meta/classes-recipe/bin_package.bbclass | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > --
> > 2.35.3
>
> //Peter
>
>From the bugzilla entry [1] which added the feature and from the commit
adding the class [2] it looks to me that the class should simplify adding
binaries externally built for the target.
Having the users of the class having to add the used libc / compiler
shared objects to not trigger a qa warning seems really wrong to me.
Additionally I don't see the advantage in not installing the base
dependencies. Doing anything usefull in a build would need to build
them anyway for some other recipe, so one would save creating a few
hard links. Do I miss something here?
So IMHO a recipe which inherits the class and really does not like the
default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Regards
Max
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186832):
https://lists.openembedded.org/g/openembedded-core/message/186832
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone][PATCH] efivar: backport 5 patches to fix build with gold
On Mon, Jul 31, 2023 at 10:30 PM Martin Jansa via lists.openembedded.org wrote: > * LDFLAGS += "-fuse-ld=bfd" in the recipe doesn't work and > it still fails to build with ld-is-gold in DISTRO_FEATURES > > removal of this line sent to master in: > https://lists.openembedded.org/g/openembedded-core/message/185167 > > * the most important ones are the 1st which removes --add-needed > and the last which removes src/include/workarounds.mk completely > while 2-4 patches just update src/include/workarounds.mk for the > last one to apply cleanly > > * alternatively we can bump SRCREV to latest 38 as master did in: > > https://git.openembedded.org/openembedded-core/commit/?id=4df808c616f847d90203582fd950a49bb8360dd0 > which brings 23 commits, but instead of adding 5 more patches > allows to remove 5 > Steve: this should be OK to backport, unless you want me to send backport of above minor upgrade instead. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186831): https://lists.openembedded.org/g/openembedded-core/message/186831 Mute This Topic: https://lists.openembedded.org/mt/100470272/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
If previous PRs have stalled, it may help to open a fresh one, which
you can drive yourself. You can reuse and rebase previous patches by
others as needed.
Alex
On Mon, 28 Aug 2023 at 14:59, Martin Hundebøll wrote:
>
> On Mon, 2023-08-28 at 14:57 +0200, Alexander Kanavin wrote:
> > Thanks, make/ninja jobserver is something we've been talking about
> > since forever, and it's great to see actual code.
> >
> > I suppose the biggest obstacle is that ninja support hasn't yet
> > landed
> > upstream, and I'd like to ensure it does. Also, a link to the pull
> > request is missing? :)
>
> Indeed, upstream seems to ignore the pull request :(
>
> Link references are like attachments: easy to forget... Here it is:
> https://github.com/ninja-build/ninja/issues/1139
>
> // Martin
>
> > On Mon, 28 Aug 2023 at 14:48, Martin Hundeb?ll
> > wrote:
> > >
> > > Ninja doesn't (yet) support the GNU Make jobserver out of the box,
> > > but
> > > there is a pull request adding that support[1]. Switch the SRC_URI
> > > and
> > > SRCREV to point at the source of that pull request, to make ninja
> > > play
> > > nicely together with the recently added jobserver class.
> > >
> > > Signed-off-by: Martin Hundebøll
> > > ---
> > > .../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb}| 4
> > > ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb =>
> > > ninja_1.12.0.bb} (84%)
> > >
> > > diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > > b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > > similarity index 84%
> > > rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > > rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > > index 8e297ec4d4..9abdd40a92 100644
> > > --- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > > +++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > > @@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
> > > "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
> > >
> > > DEPENDS = "re2c-native ninja-native"
> > >
> > > -SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
> > > +SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
> > >
> > > -SRC_URI = "git://github.com/ninja-
> > > build/ninja.git;branch=release;protocol=https"
> > > +SRC_URI = "git://github.com/stefanb2/ninja.git;branch=topic-issue-
> > > 1139-part-3-jobserver-fifo;protocol=https"
> > > UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
> > >
> > > S = "${WORKDIR}/git"
> > > --
> > > 2.41.0
> > >
> > >
> > >
> > >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186830):
https://lists.openembedded.org/g/openembedded-core/message/186830
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
On Mon, 2023-08-28 at 14:57 +0200, Alexander Kanavin wrote:
> Thanks, make/ninja jobserver is something we've been talking about
> since forever, and it's great to see actual code.
>
> I suppose the biggest obstacle is that ninja support hasn't yet
> landed
> upstream, and I'd like to ensure it does. Also, a link to the pull
> request is missing? :)
Indeed, upstream seems to ignore the pull request :(
Link references are like attachments: easy to forget... Here it is:
https://github.com/ninja-build/ninja/issues/1139
// Martin
> On Mon, 28 Aug 2023 at 14:48, Martin Hundeb?ll
> wrote:
> >
> > Ninja doesn't (yet) support the GNU Make jobserver out of the box,
> > but
> > there is a pull request adding that support[1]. Switch the SRC_URI
> > and
> > SRCREV to point at the source of that pull request, to make ninja
> > play
> > nicely together with the recently added jobserver class.
> >
> > Signed-off-by: Martin Hundebøll
> > ---
> > .../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} | 4
> > ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb =>
> > ninja_1.12.0.bb} (84%)
> >
> > diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > similarity index 84%
> > rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > index 8e297ec4d4..9abdd40a92 100644
> > --- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> > +++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> > @@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
> > "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
> >
> > DEPENDS = "re2c-native ninja-native"
> >
> > -SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
> > +SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
> >
> > -SRC_URI = "git://github.com/ninja-
> > build/ninja.git;branch=release;protocol=https"
> > +SRC_URI = "git://github.com/stefanb2/ninja.git;branch=topic-issue-
> > 1139-part-3-jobserver-fifo;protocol=https"
> > UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
> >
> > S = "${WORKDIR}/git"
> > --
> > 2.41.0
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186829):
https://lists.openembedded.org/g/openembedded-core/message/186829
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
Thanks, make/ninja jobserver is something we've been talking about
since forever, and it's great to see actual code.
I suppose the biggest obstacle is that ninja support hasn't yet landed
upstream, and I'd like to ensure it does. Also, a link to the pull
request is missing? :)
Alex
On Mon, 28 Aug 2023 at 14:48, Martin Hundeb?ll wrote:
>
> Ninja doesn't (yet) support the GNU Make jobserver out of the box, but
> there is a pull request adding that support[1]. Switch the SRC_URI and
> SRCREV to point at the source of that pull request, to make ninja play
> nicely together with the recently added jobserver class.
>
> Signed-off-by: Martin Hundebøll
> ---
> .../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb}| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} (84%)
>
> diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> similarity index 84%
> rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
> rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
> index 8e297ec4d4..9abdd40a92 100644
> --- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
> +++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
> @@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
>
> DEPENDS = "re2c-native ninja-native"
>
> -SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
> +SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
>
> -SRC_URI =
> "git://github.com/ninja-build/ninja.git;branch=release;protocol=https"
> +SRC_URI =
> "git://github.com/stefanb2/ninja.git;branch=topic-issue-1139-part-3-jobserver-fifo;protocol=https"
> UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
>
> S = "${WORKDIR}/git"
> --
> 2.41.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186828):
https://lists.openembedded.org/g/openembedded-core/message/186828
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 5/5] contrib: add python service and systemd unit to run shared jobserver
For CI setups that might end up building multiple yocto builds in
parallel, a shared jobserver can reduce the total load of the system.
Setting up such a jobserver is simple, but it does require a process
hanging around to keep the jobserver fifo open (to avoid blocking token
requests).
Add a simple python script that creates such a jobserver fifo and waits
forever. Also add a systemd unit file to start the python service at
boot.
The systemd unit can be installed in $HOME/.config/systemd/user/, but
one might need to add a droplet config (i.e. `systemctl --user edit
jobserver.service`) to setup the PYTHONPATH variable to make the python
script loadable.
Signed-off-by: Martin Hundebøll
---
contrib/jobserver/jobserver.py | 78 +
contrib/jobserver/jobserver.service | 10
2 files changed, 88 insertions(+)
create mode 100644 contrib/jobserver/jobserver.py
create mode 100644 contrib/jobserver/jobserver.service
diff --git a/contrib/jobserver/jobserver.py b/contrib/jobserver/jobserver.py
new file mode 100644
index 00..41b085f47f
--- /dev/null
+++ b/contrib/jobserver/jobserver.py
@@ -0,0 +1,78 @@
+#!/usr/bin/env python3
+
+from pathlib import Path
+from threading import Event
+import argparse
+import os
+import shutil
+import signal
+
+resumed = Event()
+runtime_dir = os.environ.get("XDG_RUNTIME_DIR", "/run")
+
+def signal_handler(signum, _frame):
+"""Wait for an external signal exit the process gracefully."""
+resumed.set()
+
+
+def main(path, user, group, mode, jobs):
+"""Setup a fifo to used as jobserver shared between builds."""
+try:
+path.unlink(missing_ok=True)
+os.mkfifo(path)
+shutil.chown(path, user, group)
+os.chmod(path, mode)
+except (FileNotFoundError, PermissionError) as exc:
+raise SystemExit(f"failed to create fifo: {path}: {exc.strerror}")
+
+print(f"jobserver: {path}: {jobs} jobs")
+fifo = os.open(path, os.O_RDWR)
+os.write(fifo, b"+" * jobs)
+
+print("jobserver: ready; waiting indefinitely")
+signal.signal(signal.SIGTERM, signal_handler)
+signal.signal(signal.SIGINT, signal_handler)
+resumed.wait()
+
+print("jobserver: exiting")
+path.unlink()
+os.close(fifo)
+
+
+if __name__ == "__main__":
+parser = argparse.ArgumentParser(
+prog='Make jobserver',
+description='Simple application to instantiate a jobserver fifo and
hang around',
+)
+parser.add_argument(
+"--mode",
+help="Permission to apply to jobserver fifo",
+type=lambda v: int(v, 8),
+default=0o0666,
+)
+parser.add_argument(
+"--user",
+help="Username or id to assign ownership of fifo to",
+default=os.getuid(),
+)
+parser.add_argument(
+"--group",
+help="Groupname of id to assign ownership of fifo to",
+default=os.getgid(),
+)
+parser.add_argument(
+"path",
+help="Path to jobserver fifo path",
+type=Path,
+nargs='?',
+default=f"{runtime_dir}/jobserver",
+)
+parser.add_argument(
+"jobs",
+help="Number of tokens to load jobserver with",
+type=int,
+nargs='?',
+default=os.cpu_count(),
+)
+args = parser.parse_args()
+main(args.path, args.user, args.group, args.mode, args.jobs)
diff --git a/contrib/jobserver/jobserver.service
b/contrib/jobserver/jobserver.service
new file mode 100644
index 00..bbc7167ac0
--- /dev/null
+++ b/contrib/jobserver/jobserver.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=Shared jobserver fifo
+
+[Service]
+Type=simple
+Environment=PYTHONUNBUFFERED=1
+ExecStart=python jobserver.py
+
+[Install]
+WantedBy=multi-user.target
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186826):
https://lists.openembedded.org/g/openembedded-core/message/186826
Mute This Topic: https://lists.openembedded.org/mt/101009094/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 1/5] classes: jobserver: support gnu make fifo jobserver
Add a class to implement the gnu make fifo style jobserver. The class
can be activated by symply adding an `INHERIT += "jobserver"` to the
local configuration.
Furthermore, one can configure an external jobserver (i.e. a server
shared between multiple builds), by configured the `JOBSERVER_FIFO`
variable to point at an existing jobserver fifo.
The jobserver class uses the fifo style jobserver, which doesn't require
passing open file descriptors around. It does, however, require
make-4.4, which isn't available in common distro yet. To work around
this, the class make all recipes (except make and its dependencies
itself) depend on `virtual/make-native`.
Signed-off-by: Martin Hundebøll
---
meta/classes-global/jobserver.bbclass | 80 +++
meta/conf/bitbake.conf| 2 +-
2 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 meta/classes-global/jobserver.bbclass
diff --git a/meta/classes-global/jobserver.bbclass
b/meta/classes-global/jobserver.bbclass
new file mode 100644
index 00..c76909fe50
--- /dev/null
+++ b/meta/classes-global/jobserver.bbclass
@@ -0,0 +1,80 @@
+JOBSERVER_FIFO ?= ""
+JOBSERVER_FIFO[doc] = "Path to external jobserver fifo to use instead of
creating a per-build server."
+
+addhandler jobserver_setup_fifo
+jobserver_setup_fifo[eventmask] = "bb.event.ConfigParsed"
+
+python jobserver_setup_fifo() {
+# don't setup a per-build fifo, if an external one is configured
+if d.getVar("JOBSERVER_FIFO"):
+return
+
+# don't use a job-server if no parallelism is configured
+jobs = oe.utils.parallel_make(d)
+if jobs in (None, 1):
+return
+
+# reduce jobs by one as a token has implicitly been handed to the
+# process requesting tokens
+jobs -= 1
+
+fifo = d.getVar("TMPDIR") + "/jobserver_fifo"
+
+# and old fifo might be lingering; remove it
+if os.path.exists(fifo):
+os.remove(fifo)
+
+# create a new fifo to use for communicating tokens
+os.mkfifo(fifo)
+
+# fill the fifo with the number of tokens to hand out
+wfd = os.open(fifo, os.O_RDWR)
+written = os.write(wfd, b"+" * jobs)
+if written != (jobs):
+bb.error("Failed to fil make fifo: {} != {}".format(written, jobs))
+
+# configure the per-build fifo path to use
+d.setVar("JOBSERVER_FIFO", fifo)
+}
+
+python () {
+# don't configure the fifo if none is defined
+fifo = d.getVar("JOBSERVER_FIFO")
+if not fifo:
+return
+
+# avoid making make-native or its dependencies depend on make-native itself
+if d.getVar("PN") in (
+"make-native",
+"libtool-native",
+"pkgconfig-native",
+"automake-native",
+"autoconf-native",
+"m4-native",
+"texinfo-dummy-native",
+"gettext-minimal-native",
+"quilt-native",
+"gnu-config-native",
+):
+return
+
+# don't make unwilling recipes depend on make-native
+if d.getVar('INHIBIT_DEFAULT_DEPS', False):
+return
+
+# make other recipes depend on make-native to make sure it is new enough to
+# support the --jobserver-auth=fifo: syntax (from make-4.4 and
onwards)
+d.appendVar("DEPENDS", " virtual/make-native")
+
+# disable the "-j " flag, as that overrides the jobserver fifo tokens
+d.setVar("PARALLEL_MAKE", "")
+d.setVar("PARALLEL_MAKEINST", "")
+
+# set and export the jobserver in the environment
+d.appendVar("MAKEFLAGS", " --jobserver-auth=fifo:" + fifo)
+d.setVarFlag("MAKEFLAGS", "export", "1")
+
+# ignore the joberserver argument part of MAKEFLAGS in the hash, as that
+# shouldn't change the build output
+d.appendVarFlag("MAKEFLAGS", "vardepvalueexclude", "|
--jobserver-auth=fifo:" + fifo)
+}
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index cf7ff3328c..8cf188270b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -946,7 +946,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH
BBPATH BBSERVER DL_DI
BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot
DEPLOY_DIR \
SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \
SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES
\
-OMP_NUM_THREADS BB_CURRENTTASK"
+OMP_NUM_THREADS BB_CURRENTTASK JOBSERVER_FIFO"
BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_IGNORE_PATHS
BUILDHISTORY_DIR \
SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID
\
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186824):
https://lists.openembedded.org/g/openembedded-core/message/186824
Mute This Topic: https://lists.openembedded.org/mt/101009092/21656
Group Owner:
[OE-core] [RFC PATCH 2/5] scripts: build-env: allow passing JOBSERVER_FIFO from environment
Sharing a common jobserver fifo between multiple (containerized) builds is much easier, if an administrator can configure said jobserver fifo path in the environment. Append the JOBSERVER_FIFO variable name to the list of variables configurable through the environment. Signed-off-by: Martin Hundebøll --- scripts/oe-buildenv-internal | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 2fdb19565a..c8e67ffb8f 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -112,7 +112,7 @@ HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \ SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA BB_SETSCENE_ENFORCE \ -BB_LOGCONFIG" +BB_LOGCONFIG JOBSERVER_FIFO" BB_ENV_PASSTHROUGH_ADDITIONS="$(echo $BB_ENV_PASSTHROUGH_ADDITIONS $BB_ENV_PASSTHROUGH_ADDITIONS_OE | tr ' ' '\n' | LC_ALL=C sort --unique | tr '\n' ' ')" -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186823): https://lists.openembedded.org/g/openembedded-core/message/186823 Mute This Topic: https://lists.openembedded.org/mt/101009091/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 4/5] qemu: enable parallel builds when using the jobserver class
If the jobserver class is enabled, the PARALLEL_MAKE variable is unset in
favor of configuring a shared jobserver in the MAKEFLAGS variable. However,
the qemu makefile translates the missing `-j` argument to `-j1` when
calling into meson / ninja. Avoid this by setting `-j` without a value.
For normal/GNU make, this can result in a fork bomb, but for ninja, it
simply makes it use the jobserver fifa instead.
Signed-off-by: Martin Hundebøll
---
meta/recipes-devtools/qemu/qemu.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index ea02bf0c73..7da05fcbf4 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -110,6 +110,11 @@ EXTRA_OECONF = " \
${PACKAGECONFIG_CONFARGS} \
"
+# Avoid the qemu makefile treating a missing `-j` argument as `-j1` when
+# calling meson / ninja. This happens when the `jobserver` class is used, since
+# it manages parallelism in the MAKEFLAGS variable instead of PARALLEL_MAKE.
+EXTRA_OEMAKE:append = "${@' -j' if d.getVar('JOBSERVER_FIFO') else ''}"
+
B = "${WORKDIR}/build"
#EXTRA_OECONF:append = " --python=${HOSTTOOLS_DIR}/python3"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186827):
https://lists.openembedded.org/g/openembedded-core/message/186827
Mute This Topic: https://lists.openembedded.org/mt/101009095/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 3/5] ninja: build modified version with GNU Make jobserver support
Ninja doesn't (yet) support the GNU Make jobserver out of the box, but
there is a pull request adding that support[1]. Switch the SRC_URI and
SRCREV to point at the source of that pull request, to make ninja play
nicely together with the recently added jobserver class.
Signed-off-by: Martin Hundebøll
---
.../ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/ninja/{ninja_1.11.1.bb => ninja_1.12.0.bb} (84%)
diff --git a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
similarity index 84%
rename from meta/recipes-devtools/ninja/ninja_1.11.1.bb
rename to meta/recipes-devtools/ninja/ninja_1.12.0.bb
index 8e297ec4d4..9abdd40a92 100644
--- a/meta/recipes-devtools/ninja/ninja_1.11.1.bb
+++ b/meta/recipes-devtools/ninja/ninja_1.12.0.bb
@@ -6,9 +6,9 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
DEPENDS = "re2c-native ninja-native"
-SRCREV = "a524bf3f6bacd1b4ad85d719eed2737d8562f27a"
+SRCREV = "c9e21dbbc4c746ba397c0f9bec5f65c99f783c08"
-SRC_URI =
"git://github.com/ninja-build/ninja.git;branch=release;protocol=https"
+SRC_URI =
"git://github.com/stefanb2/ninja.git;branch=topic-issue-1139-part-3-jobserver-fifo;protocol=https"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
S = "${WORKDIR}/git"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186825):
https://lists.openembedded.org/g/openembedded-core/message/186825
Mute This Topic: https://lists.openembedded.org/mt/101009093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] systemd-bootchart: musl fixes have been rejected upstream
Systemd upstream has reiterated that the only supported libc implementation is glibc. Signed-off-by: Alexander Kanavin --- ...1-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch | 2 +- .../systemd-bootchart/0002-musl-does-not-provide-printf-h.patch | 2 +- .../0003-musl-does-not-provide-canonicalize_file_name.patch | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch index 12eecc989be..812900051aa 100644 --- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch @@ -12,7 +12,7 @@ systemd/0013-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch Based on work by: Khem Raj Signed-off-by: Tim Orling -Upstream-Status: Submitted [https://github.com/systemd/systemd-bootchart/pull/47] +Upstream-Status: Denied [https://github.com/systemd/systemd-bootchart/pull/47] --- src/util.h | 2 +- diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0002-musl-does-not-provide-printf-h.patch b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0002-musl-does-not-provide-printf-h.patch index 8be3bed3955..2fac76a5494 100644 --- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0002-musl-does-not-provide-printf-h.patch +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0002-musl-does-not-provide-printf-h.patch @@ -10,7 +10,7 @@ Original patch author: Emil Renner Berthing Includes work by: Khem Raj Signed-off-by: Tim Orling -Upstream-Status: Submitted [https://github.com/systemd/systemd-bootchart/pull/47] +Upstream-Status: Denied [https://github.com/systemd/systemd-bootchart/pull/47] --- Makefile.am | 4 + diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0003-musl-does-not-provide-canonicalize_file_name.patch b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0003-musl-does-not-provide-canonicalize_file_name.patch index c2c276e4588..fbe9c93d2d8 100644 --- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0003-musl-does-not-provide-canonicalize_file_name.patch +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0003-musl-does-not-provide-canonicalize_file_name.patch @@ -9,7 +9,7 @@ systemd/0007-check-for-missing-canonicalize_file_name.patch Based on work by: Khem Raj Signed-off-by: Tim Orling -Upstream-Status: Submitted [https://github.com/systemd/systemd-bootchart/pull/47] +Upstream-Status: Denied [https://github.com/systemd/systemd-bootchart/pull/47] --- src/path-util.c | 2 +- -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186822): https://lists.openembedded.org/g/openembedded-core/message/186822 Mute This Topic: https://lists.openembedded.org/mt/101008106/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
ODP: [OE-Core][PATCH v12 4/7] sstate.bbclass: add support for ACLs and xattr
Hi Richard,
I have discovered in here https://savannah.gnu.org/bugs/?59184 that this is a
bug in tar, which is already reported. The solution, which is given out there
is ugly, but on the other hand solution which will be added to tar will cause
also to update machines so we need probably to discuss the best option for us...
BR
Piotr
Od: Richard Purdie
Wysłane: czwartek, 24 sierpnia 2023 09:08
Do: Piotr Łobacz ;
openembedded-core@lists.openembedded.org
Temat: Re: [OE-Core][PATCH v12 4/7] sstate.bbclass: add support for ACLs and
xattr
On Fri, 2023-08-04 at 10:43 +0200, Piotr Łobacz wrote:
Extend `tar` command, with additional parameters, depending
on choosen package class and target distro features, in order
to support ACLs and xattr.
Additionaly set archive posix format, in order to preserve
milliseconds in timestamps for reproducibility tests.
Currently only `package_ipk` supports fully ACLs and xattr.
Signed-off-by: Piotr Łobacz
---
meta/classes-global/sstate.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-global/sstate.bbclass
b/meta/classes-global/sstate.bbclass
index 95373fd60a..ac890fc98e 100644
--- a/meta/classes-global/sstate.bbclass
+++ b/meta/classes-global/sstate.bbclass
@@ -848,7 +848,7 @@ sstate_create_package () {
mkdir --mode=0775 -p `dirname ${SSTATE_PKG}`
TFILE=`mktemp ${SSTATE_PKG}.`
- OPT="-cS"
+ OPT="--format=posix ${@bb.utils.contains('DISTRO_FEATURES', 'acl',
'--acls', '', d)} ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', '--xattrs',
'', d)} --numeric-owner -cS"
ZSTD="zstd -${SSTATE_ZSTD_CLEVEL} -T${ZSTD_THREADS}"
# Use pzstd if available
if [ -x "$(command -v pzstd)" ]; then
@@ -914,7 +914,7 @@ sstate_unpack_package () {
ZSTD="pzstd -p ${ZSTD_THREADS}"
fi
- tar -I "$ZSTD" -xvpf ${SSTATE_PKG}
+ tar -I "$ZSTD" --format=posix ${@bb.utils.contains('DISTRO_FEATURES',
'acl', '--acls', '', d)} ${@bb.utils.contains('DISTRO_FEATURES', 'xattr',
'--xattrs', '', d)} -xvpf ${SSTATE_PKG}
# update .siginfo atime on local/NFS mirror if it is a symbolic link
[ ! -h ${SSTATE_PKG}.siginfo ] || [ ! -e ${SSTATE_PKG}.siginfo ] ||
touch -a ${SSTATE_PKG}.siginfo 2>/dev/null || true
# update each symbolic link instead of any referenced file
I've been putting this through a bit more testing and sadly we're still not
quite there. In testing last night we saw a lot of failures like this:
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F58%2Fbuilds%2F7488=05%7C01%7Cp.lobacz%40welotec.com%7Cf02568261c5849e1dac308dba470e7ce%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638284577345843928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mylIx0P4MLeBaFZclc47CMwX7%2FhEliHECp6e1POGtIg%3D=0
i.e.:
WARNING: cdrtools-native-3.01-r0 do_populate_sysroot_setscene:
ExecutionError('/home/pokybuild/yocto-worker/wic/build/build/tmp/work/x86_64-linux/cdrtools-native/3.01/temp/run.sstate_unpack_package.1434763',
2, None, None)
WARNING: Logfile for failed setscene task is
/home/pokybuild/yocto-worker/wic/build/build/tmp/work/x86_64-linux/cdrtools-native/3.01/temp/log.do_populate_sysroot_setscene.1434763
WARNING: Setscene task
(/home/pokybuild/yocto-worker/wic/build/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot_setscene)
failed with exit code '1' - real task will be run instead
The sstate in question is this file:
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsstate.yoctoproject.org%2Fall%2Funiversal%2Faa%2F63%2Fsstate%3Acdrtools-native%3Ax86_64-linux%3A3.01%3Ar0%3Ax86_64%3A11%3Aaa6350f6565599ed04df25250bb5415c0e2427b77569d94039f4e21820ee6aec_populate_sysroot.tar.zst=05%7C01%7Cp.lobacz%40welotec.com%7Cf02568261c5849e1dac308dba470e7ce%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638284577345843928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IDBC6nZHweWglSxrBrGi2S%2BcXtgAk0CIbs6BX72eolo%3D=0
and the failing task log:
pokybuild@debian11-ty-1:~/yocto-worker/wic/build/build/tmp/work/x86_64-linux/cdrtools-native/3.01/temp$
cat log.do_populate_sysroot_setscene
DEBUG: Executing python function do_populate_sysroot_setscene
DEBUG: Executing shell function sstate_unpack_package
recipe-sysroot-native/
recipe-sysroot-native/sysroot-providers/
recipe-sysroot-native/sysroot-providers/cdrtools-native
recipe-sysroot-native/usr/
recipe-sysroot-native/usr/bin/
recipe-sysroot-native/usr/bin/cdda2ogg
[OE-core] [PATCH] webkitgtk: Add opengl to REQUIRED_DISTRO_FEATURES
From: Mingli Yu
webkitgtk depends on gtk4 which has the below logic, so add the
same logic for webkitgtk.
REQUIRED_DISTRO_FEATURES = "opengl"
Fixes:
ERROR: Nothing PROVIDES 'gtk4' (but
/build/layers/oe-core/meta/recipes-sato/webkit/webkitgtk_2.40.5.bb DEPENDS on
or otherwise requires it)
gtk4 was skipped: missing required distro feature 'opengl' (not in
DISTRO_FEATURES)
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-world-pkgdata',
'webkitgtk', 'gtk4']
Signed-off-by: Mingli Yu
---
meta/recipes-sato/webkit/webkitgtk_2.40.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.40.5.bb
b/meta/recipes-sato/webkit/webkitgtk_2.40.5.bb
index 7bf32e8610..39bb6a476f 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.40.5.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.40.5.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
"7de051a263668621d91a61a5eb1c3771d1a7cec900043d4afef06c326c
inherit cmake pkgconfig gobject-introspection perlnative features_check
upstream-version-is-even gi-docgen
ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
-REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
'opengl', '', d)}"
+REQUIRED_DISTRO_FEATURES = "opengl"
CVE_PRODUCT = "webkitgtk webkitgtk\+"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186818):
https://lists.openembedded.org/g/openembedded-core/message/186818
Mute This Topic: https://lists.openembedded.org/mt/101005835/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] libx11-compose-data: add CVE_PRODUCT
Hi Ross,
No, you are right. However, I think it would make sense to include CVE_PRODUCT
in xorg-lib-common.inc instead. What do you think?
Emil
From: Ross Burton
Sent: Friday, August 25, 2023 17:16
To: Emil Kronborg Andersen
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/3] libx11-compose-data: add CVE_PRODUCT
On 24 Aug 2023, at 14:41, Emil Kronborg Andersen via lists.openembedded.org
wrote:
>
> Signed-off-by: Emil Kronborg Andersen
> ---
> meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> b/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> index 2131f46213..5d5762456c 100644
> --- a/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> +++ b/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> @@ -33,3 +33,5 @@ do_install() {
> PACKAGES = "${PN}"
>
> FILES:${PN} = "${datadir}/X11/locale ${libdir}/X11/locale"
> +
> +CVE_PRODUCT += "x.org:libx11”
This is _just_ the compose data, is it feasible for this to have a CVE?
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186817):
https://lists.openembedded.org/g/openembedded-core/message/186817
Mute This Topic: https://lists.openembedded.org/mt/100935314/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone][PATCH] Qemu: Resolve undefined reference issue in CVE-2023-2861
Hi Steve,
Please find the detailed error log:
{{{
| [629/6213] Compiling C object libqemuutil.a.p/stubs_win32-kbd-hook.c.o
| [630/6213] Compiling C object libqemuutil.a.p/stubs_replay-tools.c.o
| [631/6213] Compiling C object fsdev/virtfs-proxy-helper.p/9p-marshal.c.o
| [632/6213] Compiling C object libqemuutil.a.p/stubs_xen-hw-stub.c.o
| [633/6213] Compiling C object fsdev/virtfs-proxy-helper.p/9p-iov-marshal.c.o
| [634/6213] Linking static target libqemuutil.a
| [635/6213] Compiling C object tests/qtest/libqos/libqos.fa.p/qos_external.c.o
| [636/6213] Compiling C object tests/qtest/libqos/libqos.fa.p/fw_cfg.c.o
| [637/6213] Compiling C object tests/qtest/libqos/libqos.fa.p/pci.c.o
| [638/6213] Compiling C object tests/qtest/libqos/libqos.fa.p/qgraph.c.o
| [639/6213] Compiling C object
fsdev/virtfs-proxy-helper.p/virtfs-proxy-helper.c.o
| In file included from ../qemu-6.2.0/fsdev/virtfs-proxy-helper.c:29:
| /home/siddharth/tmp/work/../qemu/6.2.0-r0/qemu-6.2.0/hw/9pfs/9p-util.h: In
function 'close_if_special_file':
| /home/siddharth/tmp/work/../qemu/6.2.0-r0/qemu-6.2.0/hw/9pfs/9p-util.h:46:9:
warning: implicit declaration of function 'qemu_fstat'
[-Wimplicit-function-declaration]
| 46 | if (qemu_fstat(fd, ) < 0) {
| | ^~
| /home/siddharth/tmp/work/../qemu/6.2.0-r0/qemu-6.2.0/hw/9pfs/9p-util.h:46:9:
warning: nested extern declaration of 'qemu_fstat' [-Wnested-externs]
| [640/6213] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-pc.c.o
| [641/6213] Linking target fsdev/virtfs-proxy-helper
| FAILED: fsdev/virtfs-proxy-helper
}}}
>
> The fix patch mentions that the issue leads to "undefined symbol error
> on certain architectures", but doesn't identify which architectures
> specifically.
>
>
- I am facing this on x86_64 and riscv architectures. Atleast these are the two
which i tried on and got the same error.
- Logically looking at the code, it should ideally fail on any machine it is
compiled on regardless of the architecture as the wrapper "qemu_fstat" is not
defined anywhere in the code and is called.
- However, since i had not tested on all architectures, i couldn't tell about
all the architectures.
- It definately made me confuse more since it had passed autobuilder test, so i
explicitly mentioned in certain architectures and not fails everywhere.
- Just building qemu with `PACKAGECONFIG:append = " libusb virtfs" ` is enough
to re-produce the error. Atleast that's what i am building it with.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186816):
https://lists.openembedded.org/g/openembedded-core/message/186816
Mute This Topic: https://lists.openembedded.org/mt/100951881/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH] tiff: fix CVE-2023-2908,CVE-2023-3316,CVE-2023-3618
Backport fixes for:
* CVE-2023-2908 - Upstream-Status: Backport from
https://gitlab.com/libtiff/libtiff/-/commit/9bd48f0dbd64fb94dc2b5b05238fde0bfdd4ff3f
* CVE-2023-3316 - Upstream-Status: Backport from
https://gitlab.com/libtiff/libtiff/-/commit/d63de61b1ec3385f6383ef9a1f453e4b8b11d536
* CVE-2023-3618 - Upstream-Status: Backport from
https://gitlab.com/libtiff/libtiff/-/commit/881a070194783561fd209b7c789a4e75566f7f37
&&
https://gitlab.com/libtiff/libtiff/-/commit/b5c7d4c4e0ac16b5cfb11acaaeaa493334f8
Signed-off-by: Hitendra Prajapati
---
.../libtiff/tiff/CVE-2023-2908.patch | 33 +++
.../libtiff/tiff/CVE-2023-3316.patch | 59 +++
.../libtiff/tiff/CVE-2023-3618-1.patch| 34 +++
.../libtiff/tiff/CVE-2023-3618-2.patch| 47 +++
meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 4 ++
5 files changed, 177 insertions(+)
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-2908.patch
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-3316.patch
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-3618-1.patch
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-3618-2.patch
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-2908.patch
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-2908.patch
new file mode 100644
index 00..cf94fd23d8
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-2908.patch
@@ -0,0 +1,33 @@
+From 8c0859a80444c90b8dfb862a9f16de74e16f0a9e Mon Sep 17 00:00:00 2001
+From: xiaoxiaoafeifei
+Date: Fri, 21 Apr 2023 13:01:34 +
+Subject: [PATCH] countInkNamesString(): fix `UndefinedBehaviorSanitizer`:
+ applying zero offset to null pointer
+
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/9bd48f0dbd64fb94dc2b5b05238fde0bfdd4ff3f]
+CVE: CVE-2023-2908
+Signed-off-by: Hitendra Prajapati
+---
+ libtiff/tif_dir.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libtiff/tif_dir.c b/libtiff/tif_dir.c
+index 349dfe4..1402c8e 100644
+--- a/libtiff/tif_dir.c
b/libtiff/tif_dir.c
+@@ -145,10 +145,10 @@ static uint16_t
+ countInkNamesString(TIFF *tif, uint32_t slen, const char *s)
+ {
+ uint16_t i = 0;
+- const char *ep = s + slen;
+- const char *cp = s;
+
+ if (slen > 0) {
++ const char *ep = s + slen;
++ const char *cp = s;
+ do {
+ for (; cp < ep && *cp != '\0'; cp++) {}
+ if (cp >= ep)
+--
+2.25.1
+
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3316.patch
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3316.patch
new file mode 100644
index 00..1aa4ba45ac
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3316.patch
@@ -0,0 +1,59 @@
+From d63de61b1ec3385f6383ef9a1f453e4b8b11d536 Mon Sep 17 00:00:00 2001
+From: Su_Laus
+Date: Fri, 3 Feb 2023 17:38:55 +0100
+Subject: [PATCH] TIFFClose() avoid NULL pointer dereferencing. fix#515
+
+Closes #515
+
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/d63de61b1ec3385f6383ef9a1f453e4b8b11d536]
+CVE: CVE-2023-3316
+Signed-off-by: Hitendra Prajapati
+---
+ libtiff/tif_close.c | 11 +++
+ tools/tiffcrop.c| 5 -
+ 2 files changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/libtiff/tif_close.c b/libtiff/tif_close.c
+index 674518a..0fe7af4 100644
+--- a/libtiff/tif_close.c
b/libtiff/tif_close.c
+@@ -118,13 +118,16 @@ TIFFCleanup(TIFF* tif)
+ */
+
+ void
+-TIFFClose(TIFF* tif)
++TIFFClose(TIFF *tif)
+ {
+- TIFFCloseProc closeproc = tif->tif_closeproc;
+- thandle_t fd = tif->tif_clientdata;
++if (tif != NULL)
++{
++TIFFCloseProc closeproc = tif->tif_closeproc;
++thandle_t fd = tif->tif_clientdata;
+
+ TIFFCleanup(tif);
+- (void) (*closeproc)(fd);
++(void)(*closeproc)(fd);
++}
+ }
+
+ /* vim: set ts=8 sts=8 sw=8 noet: */
+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
+index ce77c74..cd49660 100644
+--- a/tools/tiffcrop.c
b/tools/tiffcrop.c
+@@ -2548,7 +2548,10 @@ main(int argc, char* argv[])
+ }
+ }
+
+- TIFFClose(out);
++if (out != NULL)
++{
++TIFFClose(out);
++}
+
+ return (0);
+ } /* end main */
+--
+2.25.1
+
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3618-1.patch
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3618-1.patch
new file mode 100644
index 00..8f55d2b496
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-3618-1.patch
@@ -0,0 +1,34 @@
+From 881a070194783561fd209b7c789a4e75566f7f37 Mon Sep 17 00:00:00 2001
+From: zhailiangliang
+Date: Tue, 7 Mar 2023 15:02:08 +0800
+Subject: [PATCH] Fix memory leak in tiffcrop.c
+
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/881a070194783561fd209b7c789a4e75566f7f37]
+CVE: CVE-2023-3618
+Signed-off-by: Hitendra Prajapati
+---
+
