Date   

M+ & H bugs with Milestone Movements WW37

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW37 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.4 M3

3.4 M4

 

12060

It is possible to specify a PACKAGE and a PKG_ rename that conflict

kai.kang@...

kai.kang@...

3.4 M3

3.4 M4

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.4 M3

3.4 M4

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.4 M3

3.5 M1

 

13008

toaster testing

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

13109

Implement CPE to package to Release mapping

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

13123

package.PackageTests.test_gdb_hardlink_debug failed

randy.macleod@...

randy.macleod@...

3.4 M3

3.4 M4

 

13183

bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13278

If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13520

many valgrind tests fail for arm64

randy.macleod@...

randy.macleod@...

3.4 M3

3.5 M1

 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope

richard.purdie@...

richard.purdie@...

3.4 M3

3.5 M1

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

13699

Prolonged recipe parsing times after removing tmp when the resident bitbake server is used

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13711

Parsing fails on externalsrc recipe containing both git and file in SRC_URI

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13823

fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

13888

Toaster is not starting for Django-3

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

13973

change siginfo data format to json for reproducibility? (siginfo files currently not reproducible)

richard.purdie@...

richard.purdie@...

3.4 M3

3.5 M1

 

14085

Toaster UI should know when bitbake crashed

david.reyna@...

david.reyna@...

3.4 M3

3.4 M4

 

14098

absolute path in TEMPLATECONF should be rejected or warned, makes ext-sdk uninstallable

timothy.t.orling@...

timothy.t.orling@...

3.4 M3

3.5 M1

 

14118

systemd services not enabled when using package feed

kai.kang@...

kai.kang@...

3.4 M3

3.4 M4

 

14156

gitsm: submodules are fetched as mirrored and not working as expected

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

14163

AB-INT PTEST ARM: libevent arm ptest intermittent failure

randy.macleod@...

yf3yu@...

3.4 M3

3.4 M4

 

14165

AB-INT PTEST: strace ptest intermittent failure in qual_fault-syscall.test

randy.macleod@...

randy.macleod@...

3.4 M3

3.4 M4

 

14201

Bitbake server intermittent timeout

randy.macleod@...

unassigned@...

3.4 M3

3.4 M4

 

14339

bitbake generates zombie Parser processes (hard to reproduce)

randy.macleod@...

randy.macleod@...

3.4 M3

3.4 M4

 

14340

improve detection and error reporting when oe-core is missing

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

14388

AB-INT PTEST: valgrind failed  helgrind/tests/hg05_race2

randy.macleod@...

tony.tascioglu@...

3.4 M3

3.4 M4

 

14441

possible DL_DIR cloning race condition

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

14464

AB-INT PTEST ARM: glib-2.0 glib/timeout.test failure

randy.macleod@...

unassigned@...

3.4 M3

3.4 M4

 

14486

qemu rootfs copy is taking too much time

richard.purdie@...

richard.purdie@...

3.4 M3

3.4 M4

 

14495

Implement CVE checking on all packages in a SBOM/manifest

randy.macleod@...

ross@...

3.4 M3

3.5 M2

 

14528

parselogs.ParseLogsTest.test_parselogs testimage failure

randy.macleod@...

bruce.ashfield@...

3.4 M4

3.5 M1

 

14542

Three copies of output from failing task

richard.purdie@...

richard.purdie@...

3.5 M1

3.4 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW36!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

8

mhalstead@...

2

weaverjs@...

1

randy.macleod@...

1

steve@...

1

Grand Total

13

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW37 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 33 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

michael.opdenacker@...

37

ross@...

30

david.reyna@...

22

randy.macleod@...

15

bruce.ashfield@...

15

richard.purdie@...

14

trevor.gamblin@...

11

JPEWhacker@...

10

sakib.sajal@...

10

timothy.t.orling@...

9

bluelightning@...

7

kai.kang@...

7

mhalstead@...

4

Qi.Chen@...

4

hongxu.jia@...

4

mingli.yu@...

3

chee.yang.lee@...

3

tony.tascioglu@...

2

mshah@...

2

jaewon@...

2

alexandre.belloni@...

2

yf3yu@...

2

yi.zhao@...

2

akuster808@...

2

alejandro@...

2

pgowda.cve@...

1

thomas.perrot@...

1

devendra.tewari@...

1

mostthingsweb@...

1

paul@...

1

alex.kanavin@...

1

john.kaldas.enpj@...

1

paul.gortmaker@...

1

diego.sueiro@...

1

dl9pf@...

1

douglas.royds@...

1

open.source@...

1

vinay.m.engg@...

1

kergoth@...

1

yoctoproject@...

1

nicolas.dechesne@...

1

ydirson@...

1

jon.mason@...

1

pokylinux@...

1

jeanmarie.lemetayer@...

1

Martin.Jansa@...

1

aehs29@...

1

mark.hatle@...

1

matthewzmd@...

1

tonyb@...

1

saul.wold@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 384 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


[meta-selinux][PATCH] coreutils/findutils/tar: remove pkgconfig from bbappend

Yu, Mingli
 

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


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.3.rc2)

Armin Kuster
 

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@...










Re: [yocto-autobuilder2][PATCH] add prioritizeBuilders

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


Re: [yocto-autobuilder2][PATCH] add prioritizeBuilders

Richard Purdie
 

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


Re: Sharing sstate cache across build nodes

Richard Purdie
 

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


Re: [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export Fetcher env

Mingrui Ren
 

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


[PATCH 2/2] yocto-bsp/5.13: update to v5.13.15

Bruce Ashfield
 

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


[PATCH 1/2] yocto-bsp/5.10: update to v5.10.63

Bruce Ashfield
 

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


Sharing sstate cache across build nodes

Rusty Howell
 

Hello,
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?
Thanks a lot


[meta-security][PATCH] sssd: 2.5.1 -> 2.5.2

kai
 

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


[hardknott][PATCH] sssd: fix CVE-2021-3621

kai
 

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


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.3.rc2)

Teoh, Jay Shen
 

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

-----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@...







[meta-security][dunfell][PATCH] linux-%_5.%.bbappend: drop recipe

Armin Kuster
 

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


[ANNOUNCEMENT]Milestone 3 for Yocto Project 3.4 (yocto-3.4_M3) now available

Vineela
 

Hello,

 

We are pleased to announce the third milestone release for Yocto Project 3.4 (yocto-3.4_M3) is now available for download.

 

Download:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M3

 

bitbake: 0a11696e0898c3c5108e6d7c5ad28da50e00ea66

meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a

meta-arm: 46e8fc6a67efbcc357cf507b903a3e3e133c78f7

meta-aws: 32ae20566a39454ab0ba4c80c23a32ed7c14dcaf

meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400

meta-intel: cb1bf2bdc1b20f76fde8b291a12b361a4bc2511e

meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8

meta-openembedded: 1511e25cea69b98bf2778984d7a649dad5597878

oecore: ffb886497390d4de2631bda671f2f631bc0bc7be

poky: f2728d3ec8c0589e02e9a3ce7cf8aca902cae0a3

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M3/testreport.txt

 

Thank you.

 

Vineela Tummalapalli,

Yocto Project Build and Release

vineela.tummalapalli@...

 


QA notification for completed autobuilder build (yocto-3.3.3.rc2)

Richard Purdie
 

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@...


Re: regd pTest #systemd #yocto

Khem Raj
 

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

3101 - 3120 of 57773