From: Mingli Yu <mingli.yu@...>

When enable meta-gplv2 layer [1], there comes below error:
ERROR: coreutils-6.9-r5 do_configure: QA Issue: coreutils: configure was passed unrecognised options: --without-selinux [unknown-configure-option]
ERROR: coreutils-6.9-r5 do_configure: Fatal QA errors found, failing task.

It's because the old version of coreutils under meta-gplv2 layer
doesn't support the above configure option, so move the related
pkgconfig setting to the coreutils recipe under oe-core [2] which
supports the configure option to fix the gap.

And the findutils and tar also have the problem.

[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-gplv2/
[2] https://git.openembedded.org/openembedded-core/

Signed-off-by: Mingli Yu <mingli.yu@...>
---
recipes-core/coreutils/coreutils_%.bbappend | 1 -
recipes-extended/findutils/findutils_%.bbappend | 1 -
recipes-extended/tar/tar_selinux.inc | 2 --
3 files changed, 4 deletions(-)

diff --git a/recipes-core/coreutils/coreutils_%.bbappend b/recipes-core/coreutils/coreutils_%.bbappend
index 138c23a..74e22b3 100644
--- a/recipes-core/coreutils/coreutils_%.bbappend
+++ b/recipes-core/coreutils/coreutils_%.bbappend
@@ -1,2 +1 @@
inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-selinux', '', d)}
-PACKAGECONFIG[selinux] = "--with-selinux,--without-selinux,libselinux"
diff --git a/recipes-extended/findutils/findutils_%.bbappend b/recipes-extended/findutils/findutils_%.bbappend
index 138c23a..74e22b3 100644
--- a/recipes-extended/findutils/findutils_%.bbappend
+++ b/recipes-extended/findutils/findutils_%.bbappend
@@ -1,2 +1 @@
inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-selinux', '', d)}
-PACKAGECONFIG[selinux] = "--with-selinux,--without-selinux,libselinux"
diff --git a/recipes-extended/tar/tar_selinux.inc b/recipes-extended/tar/tar_selinux.inc
index 0f64298..8c11cac 100644
--- a/recipes-extended/tar/tar_selinux.inc
+++ b/recipes-extended/tar/tar_selinux.inc
@@ -1,3 +1 @@
inherit enable-selinux
-
-PACKAGECONFIG[selinux] = "--with-selinux,--without-selinux,libselinux"
--
2.32.0

On 9/9/21 11:39 PM, Teoh, Jay Shen wrote:

Hello all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.3.rc2 We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Wednesday, 15 September.

Thanks,

Your work is much appreciated.

- armin

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Friday, 10 September, 2021 4:00 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.3.3.rc2)

A build flagged for QA (yocto-3.3.3.rc2) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc2


Build hash information:

bitbake: c7b506d11df78cfc4610db6578745eaa6220b13a
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af
meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: 7bd7e1da9034e72ca4262dba55f70b2b23499aae
oecore: 567dd35d893c5d8969d41f263a24da8fbae3fc2f
poky: 0a2ca9d60f3851515a79d5aa9ddd8b4069b5a206



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

On Sat, 2021-09-11 at 14:07 +0100, Richard Purdie via lists.yoctoproject.org
wrote:

On Thu, 2021-09-09 at 09:10 -0400, Trevor Gamblin wrote:

This prioritizeBuilders function sorts builders by the length of their
associated worker lists, so that builders that can only be assigned to a
small number of workers are assigned to those workers before other
builds that don't have specific needs when resources are limited. An
example might be when a slot is available on an Ubuntu-based worker, and
"oe-selftest-ubuntu" and "genericx86-64" build requests exist in the
queue. Since oe-selftest-ubuntu requires an Ubuntu-based worker and
genericx86-64 does not, genericx86-64 will be assigned a higher value
(lower priority) so that oe-selftest-ubuntu is assigned to that worker
first.

Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
---
builders.py | 13 +++++++++++++
master.cfg | 6 ++++++
2 files changed, 19 insertions(+)

We did merge and start using this. Unfortunately whilst I thought it would work,
it has some unfortunate side effects and we'll probably have to disable it.

If you have two build requests for say "a-full" builds, it will allocate oe-
selftest-XXX and reproducible-XXX to the XXX workers, starving generic targets.
You therefore end up with two builds running, both with half their builder
targets and it will hurt completion.

I did talk with upstream buildbot a little on irc about this challenge.

The default prioritizeBuilders function (_defaultSorter in
buildrequestdistributor.py) sorts by build request time.

They were suggesting some things which are fairly invasive like adding a
estimated completion time to the defaultSorter so we could weight slow builds.
To be honest it's beyond my comfort level with twisted defereds trying to query
and obtain the right data.

I have started wondering if we can in fact cheat and tweak the order we trigger
the builds in the a-full and a-quick targets. I think we could influence the
order of builderNames in the Triggerable and that would then change the
buildrequest timestamps so the default sorting method would work better for us
again.

I think that translates to adding your sorting method in this patch to
builderNamesFromConfigQuick and builderNamesFromConfigFull. Probably worth a
try?

Upstream gave this as an example which I think we can probably do something
with:

from datetime import datetime, timedelta

from dateutil.tz import tzutc

from twisted.internet import defer


# this stores bonuses for builders, which takes in account longer build time
builder_bonuses = {
'bldr1': timedelta(hours=1)
}

def BuilderSorter(master, builders):
# perform an asynchronous schwarzian transform, transforming None
# into a really big date, so that any
# date set to 'None' will appear at the
# end of the list during comparisons.
max_time = datetime.max
# Need to set the timezone on the date, in order
# to perform comparisons with other dates which
# have the time zone set.
max_time = max_time.replace(tzinfo=tzutc())

@defer.inlineCallbacks
def transform(bldr):
time = yield bldr.getOldestRequestTime()
if time is None:
time = max_time
else:
if bldr.name in builder_bonuses:
time = time + builder_bonuses[bldr.name]
defer.returnValue((time, bldr))

transformed = yield defer.gatherResults(
[transform(bldr) for bldr in builders])

# sort the transformed list synchronously, comparing None to the end of
# the list
def transformedKey(a):
(date, builder) = a
return (date, builder.name)

transformed.sort(key=transformedKey)

# and reverse the transform
rv = [xf[1] for xf in transformed]
return rv

c['prioritizeBuilders'] = BuilderSorter

and then we're not relying on internal bebehaviours with the sorting. It was
pointed out to me that the timestamps are only second accuracy so the global
builders list sorting would probably have more effect.

Cheers,

Richard

On Thu, 2021-09-09 at 09:10 -0400, Trevor Gamblin wrote:

This prioritizeBuilders function sorts builders by the length of their
associated worker lists, so that builders that can only be assigned to a
small number of workers are assigned to those workers before other
builds that don't have specific needs when resources are limited. An
example might be when a slot is available on an Ubuntu-based worker, and
"oe-selftest-ubuntu" and "genericx86-64" build requests exist in the
queue. Since oe-selftest-ubuntu requires an Ubuntu-based worker and
genericx86-64 does not, genericx86-64 will be assigned a higher value
(lower priority) so that oe-selftest-ubuntu is assigned to that worker
first.

Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
---
builders.py | 13 +++++++++++++
master.cfg | 6 ++++++
2 files changed, 19 insertions(+)

We did merge and start using this. Unfortunately whilst I thought it would work,
it has some unfortunate side effects and we'll probably have to disable it.

If you have two build requests for say "a-full" builds, it will allocate oe-
selftest-XXX and reproducible-XXX to the XXX workers, starving generic targets.
You therefore end up with two builds running, both with half their builder
targets and it will hurt completion.

I did talk with upstream buildbot a little on irc about this challenge.

The default prioritizeBuilders function (_defaultSorter in
buildrequestdistributor.py) sorts by build request time.

They were suggesting some things which are fairly invasive like adding a
estimated completion time to the defaultSorter so we could weight slow builds.
To be honest it's beyond my comfort level with twisted defereds trying to query
and obtain the right data.

I have started wondering if we can in fact cheat and tweak the order we trigger
the builds in the a-full and a-quick targets. I think we could influence the
order of builderNames in the Triggerable and that would then change the
buildrequest timestamps so the default sorting method would work better for us
again.

I think that translates to adding your sorting method in this patch to
builderNamesFromConfigQuick and builderNamesFromConfigFull. Probably worth a
try?

Cheers,

Richard

On Fri, 2021-09-10 at 11:16 -0600, Rusty Howell wrote:

We are having a problem with the PR server resetting the PR number it is
returning for a given package/arch/checksum.  Our setup is as follows:  We
have multiple linux servers being used as build nodes. Each node can build any
one of four MACHINE types that we have defined in our distro. These builds
actually happen inside a docker container on the build nodes.  We have a
global PR server running on a separate server.

Each node has it's own SSTATE_DIR, DL_DIR, and all bitbake builds on a node
will use the same SSTATE_DIR, DL_DIR. Those directories are shared with the
docker containers.

Our distro has many recipes that have a git SRC_URI with a branch name as the
rev. So they need to use AUTOINC.
What we are noticing is that once in a while, the revs being served out by the
PR server will be reset back to 0, and thus break upgrade-ability with the
debian packages.

I have been unable to find much information about how to properly configure
multiple build nodes so that they all have consistent PR values from the PR
server.

I know there are several directories that might be necessary to achieve my
goal.
PERSISTENT_DIR, SSTATE_DIR, BUILDHISTORY_DIR, DL_DIR

Can someone help explain which dirs should/must be shared via NFS/smb across
all build nodes? Which directories are node-specific and only need to be
cached locally (but not NFS) and used for all local build jobs? Does changing
the MACHINE type on the build affect how/if these directories can be shared?

In general you need the sstate and the PR server to match. Using multiple
different pools of sstate with the same PR server will probably not work so
well.

It won't matter about DL_DIR or PERSISTENT_DIR.

Cheers,

Richard

Hi Richard,


On 06/09/2021 17:41, Richard Purdie wrote:

Hi,

Thanks for the patch. This isn't ready to be merged yet though as there are some
issues.

On Mon, 2021-08-23 at 15:18 +0800, jiladahe1997@... wrote:

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index e0d920f2fc..29cb694790 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -111,7 +111,8 @@ 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 HOME PATH GIT_SSH GIT_SSL_CAINFO GIT_SMART_HTTP DBUS_SESSION_BUS_ADDRESS \
+P4CONFIG SSL_CERT_FILE AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION"
BB_ENV_EXTRAWHITE="$(echo $BB_ENV_EXTRAWHITE $BB_ENV_EXTRAWHITE_OE | tr ' ' '\n' | LC_ALL=C sort --unique | tr '\n' ' ')"

I think if you leave BB_ORIGENV handling in place, these latter changes
shouldn't be needed?

If you need to be able to pass extra variables into the fetcher, I think we
could/should add API for additions rather than allowing the whole list to be
customised. Without stating which problem you're solving, guessing what you
really need is hard though. A better description of the issue you're seeing
would help a lot.

Cheers,

Richard

Thanks for your reply.

The issue I have is that I have to pass additional variables into fetcher. More specifically,
I'm using a git:// protocol proxy tool, which requires GIT_SOCKS_PROXY variable.

I have made a bit more changes in this patch, I'm trying to make the code'perfect'.
But as you said, we could also add an API for adding additional variables into fetcher,
that's safe for back compatibility, but a bit more complicated for furture maintainability.
Please tell me which one you prefer.


By the way, I found two recent commits on this issue:
 (commit ID)
348384135272ae7c62a11eeabcc43eddc957811f
5dce2f3da20a14c0eb5229696561b0c5f6fce54c
which means the variables used by fetcher may change frequently.

I think it's a good a feature if we could add custom variables into fetcher. For example,
we could fetch private code by adding username or password, or we could adding custom
proxy tools.


Thanks,

Mingrui Ren

From: Bruce Ashfield <bruce.ashfield@...>

Updating the reference boards to match the oe-core kernel version.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_5.13.bbappend | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
index 6089a94d75..daf5fd2cd6 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "fe64083abac67ac736aa0133f3a4088286aece40"
-SRCREV_machine:genericx86-64 ?= "fe64083abac67ac736aa0133f3a4088286aece40"
-SRCREV_machine:edgerouter ?= "7b80606f7484fb1967a261e7e262de9adeb7ed59"
-SRCREV_machine:beaglebone-yocto ?= "e486ea86794d62e7e6adbb3a2b2fd65222f323f7"
+SRCREV_machine:genericx86 ?= "7280c93f5599946db3add473eeb05b34c364938d"
+SRCREV_machine:genericx86-64 ?= "7280c93f5599946db3add473eeb05b34c364938d"
+SRCREV_machine:edgerouter ?= "a832a0390e96c4f014d7b2bf9f161ac9477140f7"
+SRCREV_machine:beaglebone-yocto ?= "dbdc921374c057a75b2df92302124994e241ca51"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE:edgerouter = "edgerouter"
COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"

-LINUX_VERSION:genericx86 = "5.13.11"
-LINUX_VERSION:genericx86-64 = "5.13.11"
-LINUX_VERSION:edgerouter = "5.13.11"
-LINUX_VERSION:beaglebone-yocto = "5.13.11"
+LINUX_VERSION:genericx86 = "5.13.15"
+LINUX_VERSION:genericx86-64 = "5.13.15"
+LINUX_VERSION:edgerouter = "5.13.15"
+LINUX_VERSION:beaglebone-yocto = "5.13.15"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Updating the reference platforms to match the latest 5.10 -stable in
oe-core.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_5.10.bbappend | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 1e14229c23..a7ef143dc9 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "c274623910704eefcc98380a17649889ac7e9408"
-SRCREV_machine:genericx86-64 ?= "c274623910704eefcc98380a17649889ac7e9408"
-SRCREV_machine:edgerouter ?= "ac089d661362ba857e235c5630242039b150ae26"
-SRCREV_machine:beaglebone-yocto ?= "a6df693a45f5787d4254e0998f52b4465b2a5efe"
+SRCREV_machine:genericx86 ?= "164ed895bc1e94722e80fe6496b176f6bb815cd4"
+SRCREV_machine:genericx86-64 ?= "164ed895bc1e94722e80fe6496b176f6bb815cd4"
+SRCREV_machine:edgerouter ?= "4ab94e777d8b41ee1ee4c279259e9733bc8049b1"
+SRCREV_machine:beaglebone-yocto ?= "941cc9c3849f96f7eaf109b1e35e05ba366aca56"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE:edgerouter = "edgerouter"
COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"

-LINUX_VERSION:genericx86 = "5.10.55"
-LINUX_VERSION:genericx86-64 = "5.10.55"
-LINUX_VERSION:edgerouter = "5.10.55"
-LINUX_VERSION:beaglebone-yocto = "5.10.55"
+LINUX_VERSION:genericx86 = "5.10.63"
+LINUX_VERSION:genericx86-64 = "5.10.63"
+LINUX_VERSION:edgerouter = "5.10.63"
+LINUX_VERSION:beaglebone-yocto = "5.10.63"
--
2.19.1

From: Kai Kang <kai.kang@...>

SSSD 2.5.2 Highlights
* General information
- originalADgidNumber attribute in the SSSD cache is now indexed

* New features
- Debug messages in data provider include a unique request ID that can
be used to track the request from its start to its end (requires
libtevent >= 0.11.0)

* Important fixes
- Update large files in the files provider in batches to avoid timeouts

* Configuration changes
- Add new config option fallback_to_nss

Full release notes:
* https://sssd.io/release-notes/sssd-2.5.2.html

And backport patch to fix CVE-2021-3621.

CVE: CVE-2021-3621

Signed-off-by: Kai Kang <kai.kang@...>
---
.../sssd/files/CVE-2021-3621.patch | 288 ++++++++++++++++++
.../sssd/{sssd_2.5.1.bb => sssd_2.5.2.bb} | 3 +-
2 files changed, 290 insertions(+), 1 deletion(-)
create mode 100644 recipes-security/sssd/files/CVE-2021-3621.patch
rename recipes-security/sssd/{sssd_2.5.1.bb => sssd_2.5.2.bb} (97%)

diff --git a/recipes-security/sssd/files/CVE-2021-3621.patch b/recipes-security/sssd/files/CVE-2021-3621.patch
new file mode 100644
index 0000000..7a59df9
--- /dev/null
+++ b/recipes-security/sssd/files/CVE-2021-3621.patch
@@ -0,0 +1,288 @@
+Backport patch to fix CVE-2021-3621.
+
+Upstream-Status: Backport [https://github.com/SSSD/sssd/commit/7ab83f9]
+CVE: CVE-2021-3621
+
+Signed-off-by: Kai Kang <kai.kang@...>
+
+From 7ab83f97e1cbefb78ece17232185bdd2985f0bbe Mon Sep 17 00:00:00 2001
+From: Alexey Tikhonov <atikhono@...>
+Date: Fri, 18 Jun 2021 13:17:19 +0200
+Subject: [PATCH] TOOLS: replace system() with execvp() to avoid execution of
+ user supplied command
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+:relnote: A flaw was found in SSSD, where the sssctl command was
+vulnerable to shell command injection via the logs-fetch and
+cache-expire subcommands. This flaw allows an attacker to trick
+the root user into running a specially crafted sssctl command,
+such as via sudo, to gain root access. The highest threat from this
+vulnerability is to confidentiality, integrity, as well as system
+availability.
+This patch fixes a flaw by replacing system() with execvp().
+
+:fixes: CVE-2021-3621
+
+Reviewed-by: Pavel Březina <pbrezina@...>
+---
+ src/tools/sssctl/sssctl.c | 39 ++++++++++++++++-------
+ src/tools/sssctl/sssctl.h | 2 +-
+ src/tools/sssctl/sssctl_data.c | 57 +++++++++++-----------------------
+ src/tools/sssctl/sssctl_logs.c | 32 +++++++++++++++----
+ 4 files changed, 73 insertions(+), 57 deletions(-)
+
+diff --git a/src/tools/sssctl/sssctl.c b/src/tools/sssctl/sssctl.c
+index 2997dbf968..8adaf30910 100644
+--- a/src/tools/sssctl/sssctl.c
++++ b/src/tools/sssctl/sssctl.c
+@@ -97,22 +97,36 @@ sssctl_prompt(const char *message,
+ return SSSCTL_PROMPT_ERROR;
+ }
+
+-errno_t sssctl_run_command(const char *command)
++errno_t sssctl_run_command(const char *const argv[])
+ {
+ int ret;
++ int wstatus;
+
+- DEBUG(SSSDBG_TRACE_FUNC, "Running %s\n", command);
++ DEBUG(SSSDBG_TRACE_FUNC, "Running '%s'\n", argv[0]);
+
+- ret = system(command);
++ ret = fork();
+ if (ret == -1) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Unable to execute %s\n", command);
+ ERROR("Error while executing external command\n");
+ return EFAULT;
+- } else if (WEXITSTATUS(ret) != 0) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Command %s failed with [%d]\n",
+- command, WEXITSTATUS(ret));
++ }
++
++ if (ret == 0) {
++ /* cast is safe - see
++ https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
++ "The statement about argv[] and envp[] being constants ... "
++ */
++ execvp(argv[0], discard_const_p(char * const, argv));
+ ERROR("Error while executing external command\n");
+- return EIO;
++ _exit(1);
++ } else {
++ if (waitpid(ret, &wstatus, 0) == -1) {
++ ERROR("Error while executing external command '%s'\n", argv[0]);
++ return EFAULT;
++ } else if (WEXITSTATUS(wstatus) != 0) {
++ ERROR("Command '%s' failed with [%d]\n",
++ argv[0], WEXITSTATUS(wstatus));
++ return EIO;
++ }
+ }
+
+ return EOK;
+@@ -132,11 +146,14 @@ static errno_t sssctl_manage_service(enum sssctl_svc_action action)
+ #elif defined(HAVE_SERVICE)
+ switch (action) {
+ case SSSCTL_SVC_START:
+- return sssctl_run_command(SERVICE_PATH" sssd start");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "start", NULL});
+ case SSSCTL_SVC_STOP:
+- return sssctl_run_command(SERVICE_PATH" sssd stop");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "stop", NULL});
+ case SSSCTL_SVC_RESTART:
+- return sssctl_run_command(SERVICE_PATH" sssd restart");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "restart", NULL});
+ }
+ #endif
+
+diff --git a/src/tools/sssctl/sssctl.h b/src/tools/sssctl/sssctl.h
+index 0115b2457c..599ef65196 100644
+--- a/src/tools/sssctl/sssctl.h
++++ b/src/tools/sssctl/sssctl.h
+@@ -47,7 +47,7 @@ enum sssctl_prompt_result
+ sssctl_prompt(const char *message,
+ enum sssctl_prompt_result defval);
+
+-errno_t sssctl_run_command(const char *command);
++errno_t sssctl_run_command(const char *const argv[]); /* argv[0] - command */
+ bool sssctl_start_sssd(bool force);
+ bool sssctl_stop_sssd(bool force);
+ bool sssctl_restart_sssd(bool force);
+diff --git a/src/tools/sssctl/sssctl_data.c b/src/tools/sssctl/sssctl_data.c
+index 8d79b977fd..bf22913416 100644
+--- a/src/tools/sssctl/sssctl_data.c
++++ b/src/tools/sssctl/sssctl_data.c
+@@ -105,15 +105,15 @@ static errno_t sssctl_backup(bool force)
+ }
+ }
+
+- ret = sssctl_run_command("sss_override user-export "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-export",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ ERROR("Unable to export user overrides\n");
+ return ret;
+ }
+
+- ret = sssctl_run_command("sss_override group-export "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-export",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ ERROR("Unable to export group overrides\n");
+ return ret;
+@@ -158,8 +158,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override user-import "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-import",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ ERROR("Unable to import user overrides\n");
+ return ret;
+@@ -167,8 +167,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override group-import "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-import",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ ERROR("Unable to import group overrides\n");
+ return ret;
+@@ -296,40 +296,19 @@ errno_t sssctl_cache_expire(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ errno_t ret;
+- char *cmd_args = NULL;
+- const char *cachecmd = SSS_CACHE;
+- char *cmd = NULL;
+- int i;
+-
+- if (cmdline->argc == 0) {
+- ret = sssctl_run_command(cachecmd);
+- goto done;
+- }
+
+- cmd_args = talloc_strdup(tool_ctx, "");
+- if (cmd_args == NULL) {
+- ret = ENOMEM;
+- goto done;
++ const char **args = talloc_array_size(tool_ctx,
++ sizeof(char *),
++ cmdline->argc + 2);
++ if (!args) {
++ return ENOMEM;
+ }
++ memcpy(&args[1], cmdline->argv, sizeof(char *) * cmdline->argc);
++ args[0] = SSS_CACHE;
++ args[cmdline->argc + 1] = NULL;
+
+- for (i = 0; i < cmdline->argc; i++) {
+- cmd_args = talloc_strdup_append(cmd_args, cmdline->argv[i]);
+- if (i != cmdline->argc - 1) {
+- cmd_args = talloc_strdup_append(cmd_args, " ");
+- }
+- }
+-
+- cmd = talloc_asprintf(tool_ctx, "%s %s", cachecmd, cmd_args);
+- if (cmd == NULL) {
+- ret = ENOMEM;
+- goto done;
+- }
+-
+- ret = sssctl_run_command(cmd);
+-
+-done:
+- talloc_free(cmd_args);
+- talloc_free(cmd);
++ ret = sssctl_run_command(args);
+
++ talloc_free(args);
+ return ret;
+ }
+diff --git a/src/tools/sssctl/sssctl_logs.c b/src/tools/sssctl/sssctl_logs.c
+index 9ff2be05b6..ebb2c4571c 100644
+--- a/src/tools/sssctl/sssctl_logs.c
++++ b/src/tools/sssctl/sssctl_logs.c
+@@ -31,6 +31,7 @@
+ #include <ldb.h>
+ #include <popt.h>
+ #include <stdio.h>
++#include <glob.h>
+
+ #include "util/util.h"
+ #include "tools/common/sss_process.h"
+@@ -230,6 +231,7 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+ {
+ struct sssctl_logs_opts opts = {0};
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ struct poptOption options[] = {
+@@ -253,8 +255,20 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+
+ sss_signal(SIGHUP);
+ } else {
++ globbuf.gl_offs = 4;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
++ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "truncate");
++ globbuf.gl_pathv[1] = discard_const_p(char, "--no-create");
++ globbuf.gl_pathv[2] = discard_const_p(char, "--size");
++ globbuf.gl_pathv[3] = discard_const_p(char, "0");
++
+ PRINT("Truncating log files...\n");
+- ret = sssctl_run_command("truncate --no-create --size 0 " LOG_FILES);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ ERROR("Unable to truncate log files\n");
+ return ret;
+@@ -269,8 +283,8 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ const char *file;
+- const char *cmd;
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ ret = sss_tool_popt_ex(cmdline, NULL, SSS_TOOL_OPT_OPTIONAL, NULL, NULL,
+@@ -280,13 +294,19 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ return ret;
+ }
+
+- cmd = talloc_asprintf(tool_ctx, "tar -czf %s %s", file, LOG_FILES);
+- if (cmd == NULL) {
+- ERROR("Out of memory!");
++ globbuf.gl_offs = 3;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
+ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "tar");
++ globbuf.gl_pathv[1] = discard_const_p(char, "-czf");
++ globbuf.gl_pathv[2] = discard_const_p(char, file);
+
+ PRINT("Archiving log files into %s...\n", file);
+- ret = sssctl_run_command(cmd);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ ERROR("Unable to archive log files\n");
+ return ret;
diff --git a/recipes-security/sssd/sssd_2.5.1.bb b/recipes-security/sssd/sssd_2.5.2.bb
similarity index 97%
rename from recipes-security/sssd/sssd_2.5.1.bb
rename to recipes-security/sssd/sssd_2.5.2.bb
index 1c77480..76d6e03 100644
--- a/recipes-security/sssd/sssd_2.5.1.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -23,9 +23,10 @@ SRC_URI = "https://github.com/SSSD/sssd/releases/download/${PV}/sssd-${PV}.tar.g
file://drop_ntpdate_chk.patch \
file://fix-ldblibdir.patch \
file://musl_fixup.patch \
+ file://CVE-2021-3621.patch \
"

-SRC_URI[sha256sum] = "ce2f5d84a3f1750093318afd27f4fd75b1e3e75f7d80fc42d21a40cc54b58ea4"
+SRC_URI[sha256sum] = "5e21b3c7b4a2f1063d0fbdd3216d29886b6eaba153b44fb5961698367f399a0f"

inherit autotools pkgconfig gettext python3-dir features_check systemd

--
2.17.1

From: Kai Kang <kai.kang@...>

Backport patch to fix CVE-2021-3621.

CVE: CVE-2021-3621

Signed-off-by: Kai Kang <kai.kang@...>
---
.../sssd/files/CVE-2021-3621.patch | 291 ++++++++++++++++++
recipes-security/sssd/sssd_1.16.5.bb | 1 +
2 files changed, 292 insertions(+)
create mode 100644 recipes-security/sssd/files/CVE-2021-3621.patch

diff --git a/recipes-security/sssd/files/CVE-2021-3621.patch b/recipes-security/sssd/files/CVE-2021-3621.patch
new file mode 100644
index 0000000..3d2c707
--- /dev/null
+++ b/recipes-security/sssd/files/CVE-2021-3621.patch
@@ -0,0 +1,291 @@
+Backport patch to fix CVE-2021-3621.
+
+Upstream-Status: Backport [https://github.com/SSSD/sssd/commit/b4b3267]
+CVE: CVE-2021-3621
+
+Signed-off-by: Kai Kang <kai.kang@...>
+
+From b4b32677a886bc26d60ce0171505aa3ab0c82c8a Mon Sep 17 00:00:00 2001
+From: Alexey Tikhonov <atikhono@...>
+Date: Fri, 30 Jul 2021 19:05:31 +0200
+Subject: [PATCH] TOOLS: replace system() with execvp() to avoid execution of
+ user supplied command
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+:relnote: A flaw was found in SSSD, where the sssctl command was
+vulnerable to shell command injection via the logs-fetch and
+cache-expire subcommands. This flaw allows an attacker to trick
+the root user into running a specially crafted sssctl command,
+such as via sudo, to gain root access. The highest threat from this
+vulnerability is to confidentiality, integrity, as well as system
+availability.
+This patch fixes a flaw by replacing system() with execvp().
+
+:fixes: CVE-2021-3621
+
+Reviewed-by: Pavel Březina <pbrezina@...>
+---
+ src/tools/sssctl/sssctl.c | 40 +++++++++++++++++-------
+ src/tools/sssctl/sssctl.h | 2 +-
+ src/tools/sssctl/sssctl_data.c | 57 +++++++++++-----------------------
+ src/tools/sssctl/sssctl_logs.c | 31 ++++++++++++++----
+ 4 files changed, 73 insertions(+), 57 deletions(-)
+
+diff --git a/src/tools/sssctl/sssctl.c b/src/tools/sssctl/sssctl.c
+index afaa84bc0..403c89c35 100644
+--- a/src/tools/sssctl/sssctl.c
++++ b/src/tools/sssctl/sssctl.c
+@@ -97,22 +97,37 @@ sssctl_prompt(const char *message,
+ return SSSCTL_PROMPT_ERROR;
+ }
+
+-errno_t sssctl_run_command(const char *command)
++errno_t sssctl_run_command(const char *const argv[])
+ {
+ int ret;
++ int wstatus;
+
+- DEBUG(SSSDBG_TRACE_FUNC, "Running %s\n", command);
++ DEBUG(SSSDBG_TRACE_FUNC, "Running '%s'\n", argv[0]);
+
+- ret = system(command);
++ ret = fork();
+ if (ret == -1) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Unable to execute %s\n", command);
+ fprintf(stderr, _("Error while executing external command\n"));
+ return EFAULT;
+- } else if (WEXITSTATUS(ret) != 0) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Command %s failed with [%d]\n",
+- command, WEXITSTATUS(ret));
++ }
++
++ if (ret == 0) {
++ /* cast is safe - see
++ https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
++ "The statement about argv[] and envp[] being constants ... "
++ */
++ execvp(argv[0], discard_const_p(char * const, argv));
+ fprintf(stderr, _("Error while executing external command\n"));
+- return EIO;
++ _exit(1);
++ } else {
++ if (waitpid(ret, &wstatus, 0) == -1) {
++ fprintf(stderr,
++ _("Error while executing external command '%s'\n"), argv[0]);
++ return EFAULT;
++ } else if (WEXITSTATUS(wstatus) != 0) {
++ fprintf(stderr,
++ _("Command '%s' failed with [%d]\n"), argv[0], WEXITSTATUS(wstatus));
++ return EIO;
++ }
+ }
+
+ return EOK;
+@@ -132,11 +147,14 @@ static errno_t sssctl_manage_service(enum sssctl_svc_action action)
+ #elif defined(HAVE_SERVICE)
+ switch (action) {
+ case SSSCTL_SVC_START:
+- return sssctl_run_command(SERVICE_PATH" sssd start");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "start", NULL});
+ case SSSCTL_SVC_STOP:
+- return sssctl_run_command(SERVICE_PATH" sssd stop");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "stop", NULL});
+ case SSSCTL_SVC_RESTART:
+- return sssctl_run_command(SERVICE_PATH" sssd restart");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "restart", NULL});
+ }
+ #endif
+
+diff --git a/src/tools/sssctl/sssctl.h b/src/tools/sssctl/sssctl.h
+index 70fc19eff..71f798b2a 100644
+--- a/src/tools/sssctl/sssctl.h
++++ b/src/tools/sssctl/sssctl.h
+@@ -42,7 +42,7 @@ enum sssctl_prompt_result
+ sssctl_prompt(const char *message,
+ enum sssctl_prompt_result defval);
+
+-errno_t sssctl_run_command(const char *command);
++errno_t sssctl_run_command(const char *const argv[]); /* argv[0] - command */
+ bool sssctl_start_sssd(bool force);
+ bool sssctl_stop_sssd(bool force);
+ bool sssctl_restart_sssd(bool force);
+diff --git a/src/tools/sssctl/sssctl_data.c b/src/tools/sssctl/sssctl_data.c
+index cc46cafbf..8a042664c 100644
+--- a/src/tools/sssctl/sssctl_data.c
++++ b/src/tools/sssctl/sssctl_data.c
+@@ -105,15 +105,15 @@ static errno_t sssctl_backup(bool force)
+ }
+ }
+
+- ret = sssctl_run_command("sss_override user-export "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-export",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to export user overrides\n"));
+ return ret;
+ }
+
+- ret = sssctl_run_command("sss_override group-export "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-export",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to export group overrides\n"));
+ return ret;
+@@ -158,8 +158,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override user-import "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-import",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to import user overrides\n"));
+ return ret;
+@@ -167,8 +167,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override group-import "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-import",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to import group overrides\n"));
+ return ret;
+@@ -296,40 +296,19 @@ errno_t sssctl_cache_expire(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ errno_t ret;
+- char *cmd_args = NULL;
+- const char *cachecmd = SSS_CACHE;
+- char *cmd = NULL;
+- int i;
+-
+- if (cmdline->argc == 0) {
+- ret = sssctl_run_command(cachecmd);
+- goto done;
+- }
+
+- cmd_args = talloc_strdup(tool_ctx, "");
+- if (cmd_args == NULL) {
+- ret = ENOMEM;
+- goto done;
++ const char **args = talloc_array_size(tool_ctx,
++ sizeof(char *),
++ cmdline->argc + 2);
++ if (!args) {
++ return ENOMEM;
+ }
++ memcpy(&args[1], cmdline->argv, sizeof(char *) * cmdline->argc);
++ args[0] = SSS_CACHE;
++ args[cmdline->argc + 1] = NULL;
+
+- for (i = 0; i < cmdline->argc; i++) {
+- cmd_args = talloc_strdup_append(cmd_args, cmdline->argv[i]);
+- if (i != cmdline->argc - 1) {
+- cmd_args = talloc_strdup_append(cmd_args, " ");
+- }
+- }
+-
+- cmd = talloc_asprintf(tool_ctx, "%s %s", cachecmd, cmd_args);
+- if (cmd == NULL) {
+- ret = ENOMEM;
+- goto done;
+- }
+-
+- ret = sssctl_run_command(cmd);
+-
+-done:
+- talloc_free(cmd_args);
+- talloc_free(cmd);
++ ret = sssctl_run_command(args);
+
++ talloc_free(args);
+ return ret;
+ }
+diff --git a/src/tools/sssctl/sssctl_logs.c b/src/tools/sssctl/sssctl_logs.c
+index aca988c05..c85cc7a4b 100644
+--- a/src/tools/sssctl/sssctl_logs.c
++++ b/src/tools/sssctl/sssctl_logs.c
+@@ -32,6 +32,7 @@
+ #include <popt.h>
+ #include <stdio.h>
+ #include <signal.h>
++#include <glob.h>
+
+ #include "util/util.h"
+ #include "tools/common/sss_process.h"
+@@ -231,6 +232,7 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+ {
+ struct sssctl_logs_opts opts = {0};
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ struct poptOption options[] = {
+@@ -254,8 +256,19 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+
+ sss_signal(SIGHUP);
+ } else {
++ globbuf.gl_offs = 4;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
++ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "truncate");
++ globbuf.gl_pathv[2] = discard_const_p(char, "--size");
++ globbuf.gl_pathv[3] = discard_const_p(char, "0");
++
+ printf(_("Truncating log files...\n"));
+- ret = sssctl_run_command("truncate --size 0 " LOG_FILES);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to truncate log files\n"));
+ return ret;
+@@ -270,8 +283,8 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ const char *file;
+- const char *cmd;
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ ret = sss_tool_popt_ex(cmdline, NULL, SSS_TOOL_OPT_OPTIONAL, NULL, NULL,
+@@ -281,13 +294,19 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ return ret;
+ }
+
+- cmd = talloc_asprintf(tool_ctx, "tar -czf %s %s", file, LOG_FILES);
+- if (cmd == NULL) {
+- fprintf(stderr, _("Out of memory!"));
++ globbuf.gl_offs = 3;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
+ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "tar");
++ globbuf.gl_pathv[1] = discard_const_p(char, "-czf");
++ globbuf.gl_pathv[2] = discard_const_p(char, file);
+
+ printf(_("Archiving log files into %s...\n"), file);
+- ret = sssctl_run_command(cmd);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to archive log files\n"));
+ return ret;
+--
+2.33.0
+
diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_1.16.5.bb
index 9784ec7..02d0837 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -22,6 +22,7 @@ SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
file://0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch \
file://0001-nss-Collision-with-external-nss-symbol.patch \
file://0002-Provide-missing-defines-which-otherwise-are-availabl.patch \
+ file://CVE-2021-3621.patch \
"

SRC_URI[sha256sum] = "2e1a7bf036b583f686d35164f2d79bdf4857b98f51fe8b0d17aa0fa756e4d0c0"
--
2.17.1

Hello all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.3.rc2 We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Wednesday, 15 September.

Thanks,
Jay

Signed-off-by: Armin Kuster <akuster808@...>
(cherry picked from commit 833ae34c8f3222358f65e8ee3fdbac565485694e)
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-%_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-%_5.%.bbappend b/recipes-kernel/linux/linux-%_5.%.bbappend
deleted file mode 100644
index 6bc40cd..0000000
--- a/recipes-kernel/linux/linux-%_5.%.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "yama", " features/yama/yama.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.25.1

A build flagged for QA (yocto-3.3.3.rc2) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc2


Build hash information:

bitbake: c7b506d11df78cfc4610db6578745eaa6220b13a
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af
meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: 7bd7e1da9034e72ca4262dba55f70b2b23499aae
oecore: 567dd35d893c5d8969d41f263a24da8fbae3fc2f
poky: 0a2ca9d60f3851515a79d5aa9ddd8b4069b5a206



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

On 9/9/21 3:59 AM, rpaluri@... wrote:

Hi,
1. I'm aware that yocto picks up packages from respective open source
community. For e.g. dbus package is picked from freedesktop.org etc.
In this regard, what kind of tests does yocto runs to ensure that
the package that is getting picked-up is stable enough?

there is system integration testing that happens on autobuilders which you can check reports for

2. Is it Yocto, that writes pTest's to ensure that the package that is
getting picked up is stable enough?

ptests are generic and one can add more to a package but usually you will see that its trying to run the unit tests of the given package in a cross environment.

3. I could find pTest report for e.g. on Dunfell @
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.1/testreport.txt
<http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.1/testreport.txt> (Refer
"qemuarm64 PTest Result Summary" or "qemux86-64 PTest Result
Summary" section for details). The test report only details the
number of pTest's that passed, failed or skipped for respective
package. Is there any report that *details* the pTest's, which
failed, passed or skipped?

the detailed run logs would be available when you run it, I am not sure if we preserve those in release notes.

Additionally, I'm looking for pTest's for systemd, udev and glibc packages.
Below are my observations on these packages w.r.t pTests.
1. pTest for systemd package has been removed with
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/systemd?h=dunfell&id=40db00818e3b1cce8aa85ee30f3081ae9a5f8e66
<http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/systemd?h=dunfell&id=40db00818e3b1cce8aa85ee30f3081ae9a5f8e66> commit.
2. Similarly pTest for udev has been removed with
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core?h=dunfell&id=3e5e540513665105b963262c2eaf33f197a0a36c
<http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core?h=dunfell&id=3e5e540513665105b963262c2eaf33f197a0a36c>.

yes someone needs to step up and get ptests working with meson on these packages, they are temporarily removed there.

3. I don't find ptest's for glibc package either.

there is glibc-testsuite package which provides glibc testing.

As there aren't any pTests for these three packages, are there any other existing tests that can be run to validate these packages?
Thanks,
Ravi