Re: [OE-core][dunfell][PATCH] expat: Backport fix for CVE-2024-28757
On Thu, 2024-03-14 at 01:33 +0530, Ashish Sharma via
lists.openembedded.org wrote:
> Upstream ref:
> https://github.com/libexpat/libexpat/pull/842
> https://github.com/libexpat/libexpat/issues/839
>
> Upstream-Status: Backport
> [https://github.com/libexpat/libexpat/commit/072eca0b72373da103ce15f8
> f62d1d7b52695454]
This link here and in the patch points to incorrect change. Should it
be:
https://github.com/libexpat/libexpat/pull/842/commits/1d50b80cf31de87750103656f6eb693746854aa8
?
> Signed-off-by: Ashish Sharma
> ---
> .../expat/expat/CVE-2024-28757.patch | 57
> +++
> meta/recipes-core/expat/expat_2.2.9.bb | 1 +
> 2 files changed, 58 insertions(+)
> create mode 100644 meta/recipes-core/expat/expat/CVE-2024-
> 28757.patch
>
> diff --git a/meta/recipes-core/expat/expat/CVE-2024-28757.patch
> b/meta/recipes-core/expat/expat/CVE-2024-28757.patch
> new file mode 100644
> index 00..c4bdb4621a
> --- /dev/null
> +++ b/meta/recipes-core/expat/expat/CVE-2024-28757.patch
> @@ -0,0 +1,57 @@
> +From 1d50b80cf31de87750103656f6eb693746854aa8 Mon Sep 17 00:00:00
> 2001
> +From: Sebastian Pipping
> +Date: Mon, 4 Mar 2024 23:49:06 +0100
> +Subject: [PATCH] lib/xmlparse.c: Detect billion laughs attack with
> isolated
> + external parser
> +
> +When parsing DTD content with code like ..
> +
> + XML_Parser parser = XML_ParserCreate(NULL);
> + XML_Parser ext_parser = XML_ExternalEntityParserCreate(parser,
> NULL, NULL);
> + enum XML_Status status = XML_Parse(ext_parser, doc,
> (int)strlen(doc), XML_TRUE);
> +
> +.. there are 0 bytes accounted as direct input and all input from
> `doc` accounted
> +as indirect input. Now function accountingGetCurrentAmplification
> cannot calculate
> +the current amplification ratio as "(direct + indirect) / direct",
> and it did refuse
> +to divide by 0 as one would expect, but it returned 1.0 for this
> case to indicate
> +no amplification over direct input. As a result, billion laughs
> attacks from
> +DTD-only input were not detected with this isolated way of using an
> external parser.
> +
> +The new approach is to assume direct input of length not 0 but 22 --
> derived from
> +ghost input "", the shortest possible way to
> include an external
> +DTD --, and do the usual "(direct + indirect) / direct" math with
> "direct := 22".
> +
> +GitHub issue #839 has more details on this issue and its origin in
> ClusterFuzz
> +finding 66812.
> +---
> +CVE: CVE-2024-28757
> +Upstream-Status: Backport
> [https://github.com/libexpat/libexpat/commit/072eca0b72373da103ce15f8
> f62d1d7b52695454]
> +Signed-off-by: Ashish Sharma
> +---
> + expat/lib/xmlparse.c | 6 +-
> + 1 file changed, 5 insertions(+), 1 deletion(-)
> +
> +diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
> +index b884d82b5..d44baa68d 100644
> +--- a/expat/lib/xmlparse.c
> b/expat/lib/xmlparse.c
> +@@ -7787,6 +7787,8 @@ copyString(const XML_Char *s, const
> XML_Memory_Handling_Suite *memsuite) {
> +
> + static float
> + accountingGetCurrentAmplification(XML_Parser rootParser) {
> ++ //
> 1.1.12 => 22
> ++ const size_t lenOfShortestInclude = sizeof(" 'b'>") - 1;
> + const XmlBigCount countBytesOutput
> + = rootParser->m_accounting.countBytesDirect
> + + rootParser->m_accounting.countBytesIndirect;
> +@@ -7794,7 +7796,9 @@ accountingGetCurrentAmplification(XML_Parser
> rootParser) {
> + = rootParser->m_accounting.countBytesDirect
> + ? (countBytesOutput
> + / (float)(rootParser-
> >m_accounting.countBytesDirect))
> +- : 1.0f;
> ++ : ((lenOfShortestInclude
> ++ + rootParser->m_accounting.countBytesIndirect)
> ++ / (float)lenOfShortestInclude);
> + assert(! rootParser->m_parentParser);
> + return amplificationFactor;
> + }
> diff --git a/meta/recipes-core/expat/expat_2.2.9.bb b/meta/recipes-
> core/expat/expat_2.2.9.bb
> index 8a5006e59a..ea50533ed9 100644
> --- a/meta/recipes-core/expat/expat_2.2.9.bb
> +++ b/meta/recipes-core/expat/expat_2.2.9.bb
> @@ -22,6 +22,7 @@ SRC_URI =
> "git://github.com/libexpat/libexpat.git;protocol=https;branch=master
> \
> file://libtool-tag.patch \
> file://CVE-2022-40674.patch \
> file://CVE-2022-43680.patch \
> + file://CVE-2024-28757.patch \
> "
>
> SRCREV = "a7bc26b69768f7fb24f0c7976fae24b157b85b13"
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197126):
https://lists.openembedded.org/g/openembedded-core/message/197126
Mute This Topic: https://lists.openembedded.org/mt/104913576/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/2] multilib_header.bbclass:Disable multilib_header when fortran is enabled.
From: Lei Maohui
It seems that multilib header doesn't work for fortran compiler.
Signed-off-by: Lei Maohui
---
meta/classes-recipe/multilib_header.bbclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes-recipe/multilib_header.bbclass
b/meta/classes-recipe/multilib_header.bbclass
index 33f7e027f0..5c14c0a7b3 100644
--- a/meta/classes-recipe/multilib_header.bbclass
+++ b/meta/classes-recipe/multilib_header.bbclass
@@ -19,6 +19,12 @@ oe_multilib_header() {
;;
*)
esac
+ case ${FORTRAN} in
+ *fortran*)
+ return
+ ;;
+ *)
+ esac
# For MIPS: "n32" is a special case, which needs to be
# distinct from both 64-bit and 32-bit.
case ${TARGET_ARCH} in
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197125):
https://lists.openembedded.org/g/openembedded-core/message/197125
Mute This Topic: https://lists.openembedded.org/mt/104941327/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 2/2] glibc: Fix conflict error when enbale multilib on aarch64.
From: Lei Maohui
Error: Transaction test error:
file /usr/include/finclude/math-vector-fortran.h from install of
lib32-libc6-dev-2.39+git0+312e159626-r0.armv7ahf_neon conflicts with file from
package libc6-dev-2.39+git0+312e159626-r0.aarch64
Signed-off-by: Lei Maohui
---
meta/recipes-core/glibc/glibc-package.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/glibc/glibc-package.inc
b/meta/recipes-core/glibc/glibc-package.inc
index 1ef987be0a..19eb7afa81 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -167,6 +167,7 @@ do_install_armmultilib () {
oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h ieee754.h
oe_multilib_header sys/elf.h sys/procfs.h sys/ptrace.h sys/ucontext.h
sys/user.h
+ oe_multilib_header finclude/math-vector-fortran.h
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197124):
https://lists.openembedded.org/g/openembedded-core/message/197124
Mute This Topic: https://lists.openembedded.org/mt/104941120/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 0/2] glibc: Fix conflict error when enbale multilib on aarch64.
From: Lei Maohui - Fix conflict of finclude/math-vector-fortran.h error when enable multilib on aarch64. - Because multilib header doesn't work well for fortran compiler, a compile error will occur with above glibc patch. So, disable multilib_header when fortran is enabled. Lei Maohui (2): multilib_header.bbclass:Disable multilib_header when fortran is enabled. glibc: Fix conflict error when enbale multilib on aarch64. meta/classes-recipe/multilib_header.bbclass | 6 ++ meta/recipes-core/glibc/glibc-package.inc | 1 + 2 files changed, 7 insertions(+) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197123): https://lists.openembedded.org/g/openembedded-core/message/197123 Mute This Topic: https://lists.openembedded.org/mt/104941097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit
On 3/7/24 19:42, Alexander Kanavin wrote: CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 7 Mar 2024 at 11:21, Chen Qi via lists.openembedded.org wrote: You can see dnf's solution is:https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf I don't think dnf community will look into this issue. And I would expect it to be a complicated one. Because dnf's own solution looks like more of a workaround. At the same time, yocto based systems will sometimes have log_lock.pid left in target filesystems. Users typing 'ls /' will notice it. We have an OE specific patch:https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66 I can see that this OE specific patch, 0001-dnf-write-the-log-lock-to-root.patch, does solve some issue. Unfortunately, at the same time, it introduces this specific issue, a easy-to-notice one. My suggestion is that we merge this fix into 0001-dnf-write-the-log-lock-to-root.patch, because they really belong together. I guess we can't expect dnf community to devote time into this, as they've already got a solution. And I'm not sure if anyone in OE community is familiar with dnf enough to solve this issue. So let's make things a little better, avoiding users of Yocto systems see this log_lock.pid file when they type 'ls /'. If you have any other suggestion, please let us know. We need to find out why it happens, and why it happens only sometimes. If lock file does not get properly deleted that is quite possibly masking a different issue which needs fixing, and the proposed patch just sweeps it all under the carpet in the name of giving users an aesthetically pleasing rootfs. So the answer is still no. If you are having difficulty debugging the situation where the lock file does get left behind, can you provide a way for me to reproduce the issue? I just build core-image-minimal, and I'm not seeing it: alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ls tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/rootfs/ bin boot dev etc home lib media mnt proc root run sbin srv sys tmp usr var This issue only happened when dnf log rotate is happened. maybe install "a lot" packages can trigger reproduce this issue more quickly. If you can't provide that, then you can certainly still do more on your side: build core-image-minimal with plain poky, ensure the lock file gets deleted, then build your own private things where the file does not get deleted, then investigate why the code path that deletes the lock file isn't being taken in the latter case. You can see the code where the lock log (self.rotate_lock) is used in logging.py: def emit(self, record): while True: try: if self.shouldRollover(record): with self.rotate_lock: # Do rollover while preserving the mode of the new log file mode = os.stat(self.baseFilename).st_mode self.doRollover() os.chmod(self.baseFilename, mode) logging.FileHandler.emit(self, record) return except (dnf.exceptions.ProcessLockError, dnf.exceptions.ThreadLockError): time.sleep(0.01) except Exception: self.handleError(record) return And the deletion happens in lock.py: def __exit__(self, *exc_args): if self.count == 1: os.unlink(self.target) self._unlock_thread() Hi, Thanks for trying to help. I had try to find the root cause when I opened the upstream issue, but unfortunately, not got the root cause, I thought it should be a complicated one. After do more investigating recently, the root cause should be found, and I have send pull request [1] to upsteam dnf , will backport the patch if upstream accept the fix. [1] https://github.com/rpm-software-management/dnf/pull/2065 //Changqing Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197122): https://lists.openembedded.org/g/openembedded-core/message/197122 Mute This Topic: https://lists.openembedded.org/mt/104784184/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 4/4] cve-update-nvd2-native: Remove rejected CVE from database
When a CVE is updated to be rejected, matching database entries must be
removed. Otherwise:
* an incremental update is not equivalent the to an initial download.
* rejected CVEs might still appear as Unpatched in cve-check.
Signed-off-by: Yoann Congal
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 4b8d01fe84..1901641965 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -324,6 +324,10 @@ def update_db(conn, elt):
vectorString = None
cveId = elt['cve']['id']
if elt['cve']['vulnStatus'] == "Rejected":
+c = conn.cursor()
+c.execute("delete from PRODUCTS where ID = ?;", [cveId])
+c.execute("delete from NVD where ID = ?;", [cveId])
+c.close()
return
cveDesc = ""
for desc in elt['cve']['descriptions']:
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197121):
https://lists.openembedded.org/g/openembedded-core/message/197121
Mute This Topic: https://lists.openembedded.org/mt/104938853/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/4] cve-update-nvd2-native: nvd_request_next: Improve comment
Add a URL to the doc of the API used in the function. ... and fix a small typo dabase -> database Signed-off-by: Yoann Congal --- meta/recipes-core/meta/cve-update-nvd2-native.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb index 8bdb4a4b46..5bba2219d6 100644 --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb @@ -123,7 +123,8 @@ def nvd_request_wait(attempt, min_wait): def nvd_request_next(url, attempts, api_key, args, min_wait): """ -Request next part of the NVD dabase +Request next part of the NVD database +NVD API documentation: https://nvd.nist.gov/developers/vulnerabilities """ import urllib.request -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197119): https://lists.openembedded.org/g/openembedded-core/message/197119 Mute This Topic: https://lists.openembedded.org/mt/104938850/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/4] cve-update-nvd2-native: Fix CVE configuration update
When a CVE is created, it often has no precise version information and
this is stored as "-" (matching any version). After an update, version
information is added. The previous "-" must be removed, otherwise, the
CVE is still "Unpatched" for cve-check.
Signed-off-by: Yoann Congal
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 5bba2219d6..4b8d01fe84 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -357,6 +357,10 @@ def update_db(conn, elt):
[cveId, cveDesc, cvssv2, cvssv3, date, accessVector,
vectorString]).close()
try:
+# Remove any pre-existing CVE configuration. Even for partial database
+# update, those will be repopulated. This ensures that old
+# configuration is not kept for an updated CVE.
+conn.execute("delete from PRODUCTS where ID = ?", [cveId]).close()
for config in elt['cve']['configurations']:
# This is suboptimal as it doesn't handle AND/OR and negate, but
is better than nothing
for node in config["nodes"]:
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197120):
https://lists.openembedded.org/g/openembedded-core/message/197120
Mute This Topic: https://lists.openembedded.org/mt/104938851/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/4] cve-update-nvd2-native: Remove duplicated CVE_CHECK_DB_FILE definition
CVE_CHECK_DB_FILE is already defined in cve-check.bbclass which is
always inherited in cve-update-nvd2-native (There is a check line 40).
Remove it to avoid confusion. Otherwise, this should not change
anything.
Signed-off-by: Yoann Congal
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index d565887498..8bdb4a4b46 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -37,8 +37,6 @@ CVE_DB_UPDATE_ATTEMPTS ?= "5"
CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_2.db"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
-
python () {
if not bb.data.inherits_class("cve-check", d):
raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not
loaded.")
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197118):
https://lists.openembedded.org/g/openembedded-core/message/197118
Mute This Topic: https://lists.openembedded.org/mt/104938849/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 0/4] Fixes around CVE incremental update
This series should improve the incremental CVE updates (versus full-download from scratch) and, hopefully, remove the difference between the updated database and the "from-scratch" one. I've tested it by comparing a full download from scratch versus a full download on a preexisting database: no diff on the SQL dump. Patches 1&2/4 are code cleanups Fixes are in 3&4/4 Yoann Congal (4): cve-update-nvd2-native: Remove duplicated CVE_CHECK_DB_FILE definition cve-update-nvd2-native: nvd_request_next: Improve comment cve-update-nvd2-native: Fix CVE configuration update cve-update-nvd2-native: Remove rejected CVE from database meta/recipes-core/meta/cve-update-nvd2-native.bb | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197117): https://lists.openembedded.org/g/openembedded-core/message/197117 Mute This Topic: https://lists.openembedded.org/mt/104938848/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
On Thu, 14 Mar 2024 at 15:57, Enrico Scholz via lists.openembedded.org wrote: > | stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-scp' ... > | stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-sshd' ... > | stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-ssh' ... > > are these warnings really new? They are. Warnings are not allowed to creep in and linger around, so master is always free of them (except for intermittent ptest fails, which this one isn't). Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197116): https://lists.openembedded.org/g/openembedded-core/message/197116 Mute This Topic: https://lists.openembedded.org/mt/104868003/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
FWIW: meta-virtualization/master is fine since 2023-06-22:
https://git.yoctoproject.org/meta-virtualization/log/?qt=grep=Upstream-Status
There are only 4 new issues currently in master-next:
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0003-crit-pycriu-build-and-install-wheels.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0004-pycriu-attr-pycriu.version.__version__.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0005-pycriu-skip-dependency-check-during-build.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-extended/virt-manager/virt-manager/0001-setup.py-move-global-args-to-install-args.patch)
Patches missing Upstream-Status: 4 (3%)
Patches with malformed Upstream-Status: 0 (0%)
meta-oe layers were updated a day before that:
https://git.openembedded.org/meta-openembedded/commit/?id=be8c765c7c4ed48404da8fd8e813c9f3ab5ad415
and few times since then:
https://git.openembedded.org/meta-openembedded/log/?qt=grep=Upstream-Status
Some examples in other layers:
https://git.yoctoproject.org/meta-security/log/?qt=grep=Upstream-Status
https://git.yoctoproject.org/meta-raspberrypi/log/?qt=grep=Upstream-Status
https://code.qt.io/cgit/yocto/meta-qt6.git/commit/?id=d65dc4592bc7e836dbe13d37e8e0ba0a4396f4e3
https://github.com/meta-qt5/meta-qt5/commit/2c7ddcefe58099578094c91ed9a2f48f755e2dfa
https://github.com/webosose/meta-webosose/commit/eb4838a019fdbe24a50868f8ab43dd2e6d2ae52f
https://github.com/webosose/meta-webosose/commit/2c78e37ad9ceb9e236c03b44cca5b38e9d9eb2fc
https://github.com/webOS-ports/meta-webos-ports/commit/617a7ee19e9f47d993f308264ff9392ddd9a0678
https://github.com/shift-left-test/meta-shift/commit/45c96ca2adff5015c5e29c854cafeab4d1b43153
https://github.com/kraj/meta-clang/commit/ea117ca52f51224b5a1b9223ac4c3164fc3dcfb6
https://github.com/kraj/meta-clang/commit/26534d0a406caa5652dddcd4c3694d9e925b66aa
https://github.com/OSSystems/meta-browser/commit/760f47527f1cfa757aff7427fdee9e5365a94f1b
https://github.com/OSSystems/meta-browser/commit/a9e3d2b8f29ba4a2a852f30f11943cdc6afb9e60
...
Usually by me (because I had this in ERROR_QA for long time) and I'm
willing to be Upstream-Status monkey for few more days if it helps
getting this approved and resolved in even more layers :).
Cheers,
On Thu, Mar 14, 2024 at 5:17 PM Bruce Ashfield wrote:
>
> On Thu, Mar 14, 2024 at 3:09 AM Martin Jansa wrote:
> >
> > * it's enabled for patches in oe-core for very long time and I was using
> > it for many other layers as well, so most layers should be in good
> > shape
> >
> > * it's also possible to disable it for individual layer as shown
> > by oe-core in:
> >
> > https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
>
> Most people have heard my opinions on tracking status
> within files themselves (versus the revision control
> system), but that's not the point of my reply (for once!)
>
> Even with the QA error only enabled in oe-core at the
> moment, it is effectively enabled / enforced in all layers
> ... since if someone is building a product and enables
> the QA error .. all layers are going to have to comply
> even if they don't agree (since removing it from
> someone's QA checklist in a layer would probably
> fail yocto compat standards).
>
> The summary of my rambling is: that I lost the debate
> when the check was created and became an error
> in OEcore. So surprisingly, it doesn't really matter to
> me, but I lean towards doing it post release as well.
>
> Bruce
>
>
> >
> > Signed-off-by: Martin Jansa
> > ---
> > meta/classes-global/insane.bbclass | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/meta/classes-global/insane.bbclass
> > b/meta/classes-global/insane.bbclass
> > index e963001d09..9350bfa106 100644
> > --- a/meta/classes-global/insane.bbclass
> > +++ b/meta/classes-global/insane.bbclass
> > @@ -45,11 +45,10 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files
> > arch pkgconfig la \
> > already-stripped installed-vs-shipped ldflags
> > compile-host-path \
> > install-host-path pn-overrides unknown-configure-option \
> > useless-rpaths rpaths staticdev empty-dirs \
> > -patch-fuzz \
> > +patch-fuzz patch-status \
> > "
> > # Add usrmerge QA check based on distro feature
> > ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
> > usrmerge', '', d)}"
> > -ERROR_QA:append:layer-core = " patch-status"
> > WARN_QA:append:layer-core = " missing-metadata missing-maintainer"
> >
> > FAKEROOT_QA = "host-user-contaminated"
> > --
> > 2.44.0
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
Re: [OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
On Thu, Mar 14, 2024 at 3:09 AM Martin Jansa wrote:
>
> * it's enabled for patches in oe-core for very long time and I was using
> it for many other layers as well, so most layers should be in good
> shape
>
> * it's also possible to disable it for individual layer as shown
> by oe-core in:
>
> https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
Most people have heard my opinions on tracking status
within files themselves (versus the revision control
system), but that's not the point of my reply (for once!)
Even with the QA error only enabled in oe-core at the
moment, it is effectively enabled / enforced in all layers
... since if someone is building a product and enables
the QA error .. all layers are going to have to comply
even if they don't agree (since removing it from
someone's QA checklist in a layer would probably
fail yocto compat standards).
The summary of my rambling is: that I lost the debate
when the check was created and became an error
in OEcore. So surprisingly, it doesn't really matter to
me, but I lean towards doing it post release as well.
Bruce
>
> Signed-off-by: Martin Jansa
> ---
> meta/classes-global/insane.bbclass | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/meta/classes-global/insane.bbclass
> b/meta/classes-global/insane.bbclass
> index e963001d09..9350bfa106 100644
> --- a/meta/classes-global/insane.bbclass
> +++ b/meta/classes-global/insane.bbclass
> @@ -45,11 +45,10 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch
> pkgconfig la \
> already-stripped installed-vs-shipped ldflags compile-host-path \
> install-host-path pn-overrides unknown-configure-option \
> useless-rpaths rpaths staticdev empty-dirs \
> -patch-fuzz \
> +patch-fuzz patch-status \
> "
> # Add usrmerge QA check based on distro feature
> ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
> usrmerge', '', d)}"
> -ERROR_QA:append:layer-core = " patch-status"
> WARN_QA:append:layer-core = " missing-metadata missing-maintainer"
>
> FAKEROOT_QA = "host-user-contaminated"
> --
> 2.44.0
>
>
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197114):
https://lists.openembedded.org/g/openembedded-core/message/197114
Mute This Topic: https://lists.openembedded.org/mt/104922136/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
On Thu, Mar 14, 2024 at 4:32 PM Ross Burton wrote: > > On 14 Mar 2024, at 07:09, Martin Jansa via lists.openembedded.org > wrote: > > > > * it's enabled for patches in oe-core for very long time and I was using > > it for many other layers as well, so most layers should be in good > > shape > > > > * it's also possible to disable it for individual layer as shown > > by oe-core in: > > > > https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3 > > This is quite a “strong” change in policy, especially for so late in the > release cycle (post-M3). I’m on the fence but lean towards letting layers > opt-in, instead of forcing it on them and having to opt out. I was expecting some response like that :/. Other layers don't have to release at the same time as oe-core, right? And oe-core itself won't be affected much as it was already applied there. It's easy to resolve (even if it is by adding Pending to .patches without any Upstream-Status) or to opt-out if they really don't care to run one-liner to at least add Pending. Easier than resolving build failures caused by boost upgrade this late in cycle :). Also if we don't add it now, then we might not add it early in next cycle as well, because the layers opposing to fix it, won't probably add it in master branch shortly after branching for scarthgap as well. I'm using this for over a year and regularly sending patches to layers I sometimes build (and when I do I use scripts/contrib/patchreview.py to catch it in all the .patch files, not just the recipes I've built). I don't have strong opinion, I was thinking about sending this only as RFC, but IMHO it's worth considering. Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197113): https://lists.openembedded.org/g/openembedded-core/message/197113 Mute This Topic: https://lists.openembedded.org/mt/104922136/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
On 14 Mar 2024, at 07:09, Martin Jansa via lists.openembedded.org wrote: > > * it's enabled for patches in oe-core for very long time and I was using > it for many other layers as well, so most layers should be in good > shape > > * it's also possible to disable it for individual layer as shown > by oe-core in: > > https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3 This is quite a “strong” change in policy, especially for so late in the release cycle (post-M3). I’m on the fence but lean towards letting layers opt-in, instead of forcing it on them and having to opt out. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197112): https://lists.openembedded.org/g/openembedded-core/message/197112 Mute This Topic: https://lists.openembedded.org/mt/104922136/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
Richard Purdie writes:
> Some further related warnings:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/9031/steps/11/logs/warnins
| stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-config' ...
ok
I will reduce dependency from
|-RRECOMMENDS:${PN} += "openssh-config"
to
|+RRECOMMENDS:${PN}-sshd:class-target += "openssh-config"
| stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-scp' ...
| stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-sshd' ...
| stdio: WARNING: Nothing RPROVIDES 'nativesdk-openssh-ssh' ...
are these warnings really new?
Enrico
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197111):
https://lists.openembedded.org/g/openembedded-core/message/197111
Mute This Topic: https://lists.openembedded.org/mt/104868003/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
On Thu, 2024-03-14 at 15:11 +0100, Enrico Scholz wrote:
> Richard Purdie writes:
>
> > Thanks for sending this. I suspect something like this might be
> > desirable however unfortunately the timing is a little tricky as
> > we're
> > just past the feature freeze point for 5.0.
>
> ok; my fault. I delayed it too much.
>
> Would it be possible to communicate such schedules more visibly?
> E.g. put a link on https://wiki.yoctoproject.org/wiki/Releases ?
The dates are being updated here:
https://wiki.yoctoproject.org/wiki/Weekly_Status
and in weekly status emails sent to the yocto and openembedded-core
mailing lists.
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/8649/steps/14/logs/warnings
>
> ok
>
>
> > so I squashed a fix in for that. The second run had this:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6390/steps/12/logs/stdio
>
> It is difficulty for me to analyze this from the outside. The
> patchset requires that the 'openssh-sshd' IMAGE_FEATURE is set;
> installing the package manually does not suffice anymore.
That is probably something we may need to improve since lots of others
would expect installing the package to work.
I suspect meta/recipes-core/images/core-image-ptest.bb setting
IMAGE_INSTALL:append = " ${MCNAME}-ptest openssh"
will be the cause.
I don't really time to spend thinking about this now unfortunately as
there will be other priorities for the release.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197110):
https://lists.openembedded.org/g/openembedded-core/message/197110
Mute This Topic: https://lists.openembedded.org/mt/104868003/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
Richard Purdie writes: > Thanks for sending this. I suspect something like this might be > desirable however unfortunately the timing is a little tricky as we're > just past the feature freeze point for 5.0. ok; my fault. I delayed it too much. Would it be possible to communicate such schedules more visibly? E.g. put a link on https://wiki.yoctoproject.org/wiki/Releases ? > https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/8649/steps/14/logs/warnings ok > so I squashed a fix in for that. The second run had this: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6390/steps/12/logs/stdio It is difficulty for me to analyze this from the outside. The patchset requires that the 'openssh-sshd' IMAGE_FEATURE is set; installing the package manually does not suffice anymore. I can not detect such an IMAGE_FEATURE configuration in step 10; but I might miss other setup. Enrico -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197109): https://lists.openembedded.org/g/openembedded-core/message/197109 Mute This Topic: https://lists.openembedded.org/mt/104868003/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
On Thu, 2024-03-14 at 11:00 +, Richard Purdie via lists.openembedded.org wrote: > On Mon, 2024-03-11 at 10:19 -0700, Enrico Scholz via > lists.openembedded.org wrote: > > To deal with system setups, sshd was configured in the following > > way: > > > > - sshd_config is shipped completely by OE and DISTRO_FEATURES > > (pam, > > x11) are patched in during do_install > > > > --> this is difficulty to maintain; e.g. sshd_config must be > > synchronized between OpenSSH releases and OE adaptations > > manually inserted > > > > - two different configuration files (sshd_config + > > sshd_config_readonly) > > are created; IMAGE_FEATURES decides which one is used and it is > > patched > > in a ROOTFS_COMMAND in the system > > > > --> this make it difficult for third party recipes to > > incorporate > > their changes (they have to go over both files) > > > > --> the readonly HostKey locations and algorithms are hardcoded > > which makes it difficult to place them e.g. on a persistent > > /opt partition and disable e.g. ecdsa > > > > - depending on IMAGE_FEATURES (empty passwords, root login), both > > files are patched by a ROOTFS_POSTCOMMAND > > > > --> these changes are lost when pkgmgmt is used for the image > > and > > openssh being updated > > > > > > The patchset: > > > > - reduces changes to sshd_config to > > > > | Include /etc/ssh/sshd_config.d/*.conf > > > > --> This is already the done in current recipe and most mainline > > Linux distributions are doing it > > > > - moves configuration in new openssh-config recipe which is a weak > > dependency of openssh (and can be replaced by another > > IMAGE_INSTALL) > > > > Recipe ships configuration as small snippets which might contain > > dynamically created content (e.g. 'UsePAM yes') > > > > - IMAGE_FEATURE based setup is done by creating subpackages with > > the corresponding options. These subpackages are added to > > FEATURE_PACKAGES_ssh-server-openssh > > > > - readonly rootfs setup has been enhanced by > > > > | RO_KEYDIR ??= "/var/run/ssh" > > | KEY_ALGORITHMS ??= "rsa ecdsa ed25519" > > > > parameters which can be overridden. > > > Thanks for sending this. I suspect something like this might be > desirable however unfortunately the timing is a little tricky as > we're > just past the feature freeze point for 5.0. > > I know people often want to push for the inclusion of things into > something like the LTS so I did put this through the automated > testing, > just to get an idea of the potential issues. > > The first run had lots of these warnings: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/8649/steps/14/logs/warnings > > so I squashed a fix in for that. The second run had this: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6390/steps/12/logs/stdio > > which suggests ssh connections into our image testing doesn't work. > It > is unclear why that is failing there but there were indications in > the > previous build that other ssh connections were working ok. It could > be > dropbear vs openssh at a guess. That build is still ongoing too so > there may be other issues. > > Anyway I just wanted to highlight the testing results and to say that > this is something we should think about but it will have to wait > until > after 5.0 releases. > > I haven't reviewed the patches in much detail, I mainly wanted to get > the automated testing results shared. Some further related warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/9031/steps/11/logs/warnings Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197108): https://lists.openembedded.org/g/openembedded-core/message/197108 Mute This Topic: https://lists.openembedded.org/mt/104868003/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 36/36] xz: upgrade 5.4.6 -> 5.6.1
On Wed, 2024-03-13 at 15:08 +0800, wangmy via lists.openembedded.org wrote: > From: Wang Mingyu > > License-Update: > > *COPYING: > Add the license for the XZ logo. > Change most public domain parts to 0BSD. > Update COPYING about the man pages of the scripts. > *getopt.c > MSVC: Don't #include . > lib/getopt*.c: Include only HAVE_CONFIG_H is defined. > lib: Update getopt.c from Gnulib with modifications. > lib: Silence -Wsign-conversion in getopt.c. > Add SPDX license identifiers to GPL, LGPL, and FSFULLR files. > > Changelog: > = > * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) > with GCC. > * xz: Changed the messages for thread reduction due to memory > constraints to only appear under the highest verbosity level. > * Build: > - Fixed a build issue when the header file > was present on the system but the Landlock system calls were > not defined in . > - The CMake build now warns and disables NLS if both gettext > tools and pre-created .gmo files are missing. Previously, > this caused the CMake build to fail. > * Minor improvements to man pages. > * Minor improvements to tests. https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197107): https://lists.openembedded.org/g/openembedded-core/message/197107 Mute This Topic: https://lists.openembedded.org/mt/104900983/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 06/36] gnupg: upgrade 2.4.4 -> 2.4.5
On Wed, 2024-03-13 at 15:08 +0800, wangmy via lists.openembedded.org
wrote:
> From: Wang Mingyu
>
> Changelog:
> ==
> * gpg,gpgv: New option --assert-pubkey-algo.
> * gpg: Emit status lines for errors in the compression layer.
> * gpg: Fix invocation with --trusted-keys and --no-options.
> * gpgsm: Allow for a longer salt in PKCS#12 files.
> * gpgtar: Make --status-fd=2 work on Windows.
> * scd: Support for the ACR-122U NFC reader.
> * scd: Suport D-TRUST ECC cards.
> * scd: Allow auto detaching of kernel drivers; can be disabled with
> the new compatibility-flag ccid-no-auto-detach.
> * scd: Allow setting a PIN length of 6 also with a reset code for
> openpgp cards.
> * agent: Allow GET_PASSPHRASE in restricted mode.
> * dirmngr: Trust system's root CAs for checking CRL issuers.
> * dirmngr: Fix regression in 2.4.4 in fetching keys via hkps.
> * gpg-wks-client: Make option --mirror work properly w/o specifying
> domains.
> * g13,gpg-wks-client: Allow command style options as in "g13 mount
> foo".
> * Allow tilde expansion for the foo-program options.
> * Make the getswdb.sh tool usable outside the GnuPG tree.
>
> Signed-off-by: Wang Mingyu
> ---
> meta/recipes-support/gnupg/{gnupg_2.4.4.bb => gnupg_2.4.5.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-support/gnupg/{gnupg_2.4.4.bb => gnupg_2.4.5.bb}
> (97%)
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/8729
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197106):
https://lists.openembedded.org/g/openembedded-core/message/197106
Mute This Topic: https://lists.openembedded.org/mt/104900952/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/2] cve-update-nvd2-native: Add an age threshold for incremental update
Le jeu. 14 mars 2024 à 13:14, Marta Rybczynska a
écrit :
>
>
> On Wed, 13 Mar 2024, 16:15 Yoann Congal, wrote:
>
>> Add a new variable "CVE_DB_INCR_UPDATE_AGE_THRES", which can be used to
>> specify the maximum age of the database for doing an incremental update
>> For older databases, a full re-download is done.
>>
>> With a value of "0", this forces a full-redownload.
>>
>> Signed-off-by: Yoann Congal
>> ---
>> .../meta/cve-update-nvd2-native.bb| 20 +++
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
>> b/meta/recipes-core/meta/cve-update-nvd2-native.bb
>> index f21c139aa5..d565887498 100644
>> --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
>> +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
>> @@ -26,6 +26,12 @@ NVDCVE_API_KEY ?= ""
>> # Use a negative value to skip the update
>> CVE_DB_UPDATE_INTERVAL ?= "86400"
>>
>> +# CVE database incremental update age threshold, in seconds. If the
>> database is
>> +# older than this threshold, do a full re-download, else, do an
>> incremental
>> +# update. By default: the maximum allowed value from NVD: 120 days
>> (120*24*60*60)
>> +# Use 0 to force a full download.
>> +CVE_DB_INCR_UPDATE_AGE_THRES ?= "10368000"
>> +
>> # Number of attempts for each http query to nvd server before giving up
>> CVE_DB_UPDATE_ATTEMPTS ?= "5"
>>
>> @@ -172,18 +178,24 @@ def update_db_file(db_tmp_file, d, database_time):
>>
>> req_args = {'startIndex' : 0}
>>
>> -# The maximum range for time is 120 days
>> -# Force a complete update if our range is longer
>> -if (database_time != 0):
>> +incr_update_threshold = int(d.getVar("CVE_DB_INCR_UPDATE_AGE_THRES"))
>> +if database_time != 0:
>> database_date = datetime.datetime.fromtimestamp(database_time,
>> tz=datetime.timezone.utc)
>> today_date = datetime.datetime.now(tz=datetime.timezone.utc)
>> delta = today_date - database_date
>> -if delta.days < 120:
>> +if incr_update_threshold == 0:
>> +bb.note("CVE database: forced full update")
>> +elif delta < datetime.timedelta(seconds=incr_update_threshold):
>> bb.note("CVE database: performing partial update")
>> +# The maximum range for time is 120 days
>> +if delta > datetime.timedelta(days=120):
>> +bb.error("CVE database: Trying to do an incremental
>> update on a larger than supported range")
>> req_args['lastModStartDate'] = database_date.isoformat()
>> req_args['lastModEndDate'] = today_date.isoformat()
>> else:
>> bb.note("CVE database: file too old, forcing a full update")
>> +else:
>> +bb.note("CVE database: no preexisting database, do a full
>> download")
>>
>> with bb.progress.ProgressHandler(d) as ph,
>> open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f:
>>
>> --
>>
>
>
Hi Marta,
Thanks for your review!
If you had not noticed, this patch has been merged here
https://git.yoctoproject.org/poky/commit/?id=19f27037b2b785673c8f68f19ea783856f732e4d
And was used this morning by AB
https://autobuilder.yoctoproject.org/typhoon/#/builders/138/builds/1326 =>
It does not work as expected, I'm working on it.
I find naming of the variable misleading, sourcing like FORCE_FULL_DOWNLOAD
> would be more obvious.
>
I agree FORCE_FULL_DOWNLOAD is more obvious. But, I've chosen a more
nuanced variable to allow a customised workflow like the one we want on AB:
fulldownload once a day, no update for other daily cve-check runs.
> Also, I'm not sure we need a variable if the user can just delete the
> database file and force the download this way.
>
It is not usually expected of users to manually modify the content of
DL_DIR. Here, I feel like a variable is cleaner and (once documented), will
be more easy for users.
> The 120 days case is special, because its a limit set in the spec.
>
Yes, that what this hunk test:
+# The maximum range for time is 120 days
+if delta > datetime.timedelta(days=120):
+bb.error("CVE database: Trying to do an incremental update
on a larger than supported range")
maybe the error message is not clear enough?
Regards,
--
Yoann Congal
Smile ECS - Tech expert
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197105):
https://lists.openembedded.org/g/openembedded-core/message/197105
Mute This Topic: https://lists.openembedded.org/mt/104907481/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/2] cve-update-nvd2-native: Add an age threshold for incremental update
On Wed, 13 Mar 2024, 16:15 Yoann Congal, wrote:
> Add a new variable "CVE_DB_INCR_UPDATE_AGE_THRES", which can be used to
> specify the maximum age of the database for doing an incremental update
> For older databases, a full re-download is done.
>
> With a value of "0", this forces a full-redownload.
>
> Signed-off-by: Yoann Congal
> ---
> .../meta/cve-update-nvd2-native.bb| 20 +++
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> index f21c139aa5..d565887498 100644
> --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> @@ -26,6 +26,12 @@ NVDCVE_API_KEY ?= ""
> # Use a negative value to skip the update
> CVE_DB_UPDATE_INTERVAL ?= "86400"
>
> +# CVE database incremental update age threshold, in seconds. If the
> database is
> +# older than this threshold, do a full re-download, else, do an
> incremental
> +# update. By default: the maximum allowed value from NVD: 120 days
> (120*24*60*60)
> +# Use 0 to force a full download.
> +CVE_DB_INCR_UPDATE_AGE_THRES ?= "10368000"
> +
> # Number of attempts for each http query to nvd server before giving up
> CVE_DB_UPDATE_ATTEMPTS ?= "5"
>
> @@ -172,18 +178,24 @@ def update_db_file(db_tmp_file, d, database_time):
>
> req_args = {'startIndex' : 0}
>
> -# The maximum range for time is 120 days
> -# Force a complete update if our range is longer
> -if (database_time != 0):
> +incr_update_threshold = int(d.getVar("CVE_DB_INCR_UPDATE_AGE_THRES"))
> +if database_time != 0:
> database_date = datetime.datetime.fromtimestamp(database_time,
> tz=datetime.timezone.utc)
> today_date = datetime.datetime.now(tz=datetime.timezone.utc)
> delta = today_date - database_date
> -if delta.days < 120:
> +if incr_update_threshold == 0:
> +bb.note("CVE database: forced full update")
> +elif delta < datetime.timedelta(seconds=incr_update_threshold):
> bb.note("CVE database: performing partial update")
> +# The maximum range for time is 120 days
> +if delta > datetime.timedelta(days=120):
> +bb.error("CVE database: Trying to do an incremental
> update on a larger than supported range")
> req_args['lastModStartDate'] = database_date.isoformat()
> req_args['lastModEndDate'] = today_date.isoformat()
> else:
> bb.note("CVE database: file too old, forcing a full update")
> +else:
> +bb.note("CVE database: no preexisting database, do a full
> download")
>
> with bb.progress.ProgressHandler(d) as ph,
> open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f:
>
> --
>
I find naming of the variable misleading, sourcing like FORCE_FULL_DOWNLOAD
would be more obvious. Also, I'm not sure we need a variable if the user
can just delete the database file and force the download this way. The 120
days case is special, because its a limit set in the spec.
Regards,
Marta
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197104):
https://lists.openembedded.org/g/openembedded-core/message/197104
Mute This Topic: https://lists.openembedded.org/mt/104907481/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/7] Replace sshd_config patching by snippets
On Mon, 2024-03-11 at 10:19 -0700, Enrico Scholz via lists.openembedded.org wrote: > To deal with system setups, sshd was configured in the following way: > > - sshd_config is shipped completely by OE and DISTRO_FEATURES (pam, > x11) are patched in during do_install > > --> this is difficulty to maintain; e.g. sshd_config must be > synchronized between OpenSSH releases and OE adaptations > manually inserted > > - two different configuration files (sshd_config + sshd_config_readonly) > are created; IMAGE_FEATURES decides which one is used and it is patched > in a ROOTFS_COMMAND in the system > > --> this make it difficult for third party recipes to incorporate > their changes (they have to go over both files) > > --> the readonly HostKey locations and algorithms are hardcoded > which makes it difficult to place them e.g. on a persistent > /opt partition and disable e.g. ecdsa > > - depending on IMAGE_FEATURES (empty passwords, root login), both > files are patched by a ROOTFS_POSTCOMMAND > > --> these changes are lost when pkgmgmt is used for the image and > openssh being updated > > > The patchset: > > - reduces changes to sshd_config to > > | Include /etc/ssh/sshd_config.d/*.conf > > --> This is already the done in current recipe and most mainline > Linux distributions are doing it > > - moves configuration in new openssh-config recipe which is a weak > dependency of openssh (and can be replaced by another IMAGE_INSTALL) > > Recipe ships configuration as small snippets which might contain > dynamically created content (e.g. 'UsePAM yes') > > - IMAGE_FEATURE based setup is done by creating subpackages with > the corresponding options. These subpackages are added to > FEATURE_PACKAGES_ssh-server-openssh > > - readonly rootfs setup has been enhanced by > > | RO_KEYDIR ??= "/var/run/ssh" > | KEY_ALGORITHMS ??= "rsa ecdsa ed25519" > > parameters which can be overridden. Thanks for sending this. I suspect something like this might be desirable however unfortunately the timing is a little tricky as we're just past the feature freeze point for 5.0. I know people often want to push for the inclusion of things into something like the LTS so I did put this through the automated testing, just to get an idea of the potential issues. The first run had lots of these warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/8649/steps/14/logs/warnings so I squashed a fix in for that. The second run had this: https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6390/steps/12/logs/stdio which suggests ssh connections into our image testing doesn't work. It is unclear why that is failing there but there were indications in the previous build that other ssh connections were working ok. It could be dropbear vs openssh at a guess. That build is still ongoing too so there may be other issues. Anyway I just wanted to highlight the testing results and to say that this is something we should think about but it will have to wait until after 5.0 releases. I haven't reviewed the patches in much detail, I mainly wanted to get the automated testing results shared. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197103): https://lists.openembedded.org/g/openembedded-core/message/197103 Mute This Topic: https://lists.openembedded.org/mt/104868003/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 2/2] linux-firmware: add a package for ath12k firmware
From: Bartosz Golaszewski
Add the firmware package for the ATH12K module.
Signed-off-by: Bartosz Golaszewski
---
.../linux-firmware/linux-firmware_20240312.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index 390d10d2f3..4961b43ad5 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -320,7 +320,8 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
${PN}-cnm-license ${PN}-cnm \
${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k
${PN}-ath9k ${PN}-ath3k \
${PN}-gplv2-license ${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k
${PN}-ath11k ${PN}-qca \
+ ${PN}-ar3k-license ${PN}-ar3k \
+ ${PN}-ath10k-license ${PN}-ath10k ${PN}-ath11k ${PN}-ath12k
${PN}-qca \
\
${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
\
@@ -488,6 +489,10 @@ FILES:${PN}-ath11k = " \
${nonarch_base_libdir}/firmware/ath11k \
"
+FILES:${PN}-ath12k = " \
+ ${nonarch_base_libdir}/firmware/ath12k \
+"
+
FILES:${PN}-qca = " \
${nonarch_base_libdir}/firmware/qca \
"
@@ -495,6 +500,7 @@ FILES:${PN}-qca = " \
RDEPENDS:${PN}-ar3k += "${PN}-ar3k-license ${PN}-atheros-license"
RDEPENDS:${PN}-ath10k += "${PN}-ath10k-license"
RDEPENDS:${PN}-ath11k += "${PN}-ath10k-license"
+RDEPENDS:${PN}-ath12k += "${PN}-ath10k-license"
RDEPENDS:${PN}-qca += "${PN}-ath10k-license"
# For ralink
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197102):
https://lists.openembedded.org/g/openembedded-core/message/197102
Mute This Topic: https://lists.openembedded.org/mt/104923522/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/2] linux-firmware: update to 20240312
From: Bartosz Golaszewski
Update the linux-firmware recipe to the most recent upstream tag.
Signed-off-by: Bartosz Golaszewski
---
...{linux-firmware_20240220.bb => linux-firmware_20240312.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20240220.bb =>
linux-firmware_20240312.bb} (99%)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index 1fd44f4d53..390d10d2f3 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -155,7 +155,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
"
# WHENCE checksum is defined separately to ease overriding it if
# class-devupstream is selected.
-WHENCE_CHKSUM = "a344e6c28970fc7daafa81c10247aeb6"
+WHENCE_CHKSUM = "514da1cd8b363373030f0c16749feb8d"
# These are not common licenses, set NO_GENERIC_LICENSE for them
# so that the license files will be copied from fetched source
@@ -243,7 +243,7 @@ SRC_URI:class-devupstream =
"git://git.kernel.org/pub/scm/linux/kernel/git/firmw
# Pin this to the 20220509 release, override this in local.conf
SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
-SRC_URI[sha256sum] =
"bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
+SRC_URI[sha256sum] =
"b2327a54ad1897c828008caf63af5ee15469ba723a5016be58f2b44f07bd4b94"
inherit allarch
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197101):
https://lists.openembedded.org/g/openembedded-core/message/197101
Mute This Topic: https://lists.openembedded.org/mt/104923521/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] autotools: update link in comment for cross compiling
From: Jörg Sommer
Signed-off-by: Jörg Sommer
---
meta/classes-recipe/autotools.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/autotools.bbclass
b/meta/classes-recipe/autotools.bbclass
index ca76cde0e7..9359c9b4e1 100644
--- a/meta/classes-recipe/autotools.bbclass
+++ b/meta/classes-recipe/autotools.bbclass
@@ -43,7 +43,8 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir}
${base_libdir}"
# When building tools for use at build-time it's recommended for the build
# system to use these variables when cross-compiling.
-# (http://sources.redhat.com/autobook/autobook/autobook_270.html)
+# https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+#
https://stackoverflow.com/questions/24201260/autotools-cross-compilation-and-generated-sources/24208587#24208587
export CPP_FOR_BUILD = "${BUILD_CPP}"
export CPPFLAGS_FOR_BUILD = "${BUILD_CPPFLAGS}"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197100):
https://lists.openembedded.org/g/openembedded-core/message/197100
Mute This Topic: https://lists.openembedded.org/mt/104923267/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] sngrep: new recipe for ncurses SIP Messages flow viewer
This should go to the openembedded-devel list.
Alex
On Wed 13. Mar 2024 at 21.41, Jörg Sommer via lists.openembedded.org
wrote:
> From: Jörg Sommer
>
> Signed-off-by: Jörg Sommer
> ---
> .../recipes-support/sngrep/sngrep_1.8.0.bb| 37 +++
> 1 file changed, 37 insertions(+)
> create mode 100644 meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
>
> diff --git a/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
> b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
> new file mode 100644
> index 0..2824dde88
> --- /dev/null
> +++ b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
> @@ -0,0 +1,37 @@
> +SUMMARY = "Ncurses SIP Messages flow viewer"
> +DESCRIPTION = "Tool for displaying SIP calls message flows from terminal"
> +HOMEPAGE = "https://github.com/irontec/sngrep;
> +BUGTRACKER = "https://github.com/irontec/sngrep/issues;
> +SECTION = "console/network"
> +LICENSE = "GPL-3.0-or-later & OpenSSL"
> +LIC_FILES_CHKSUM = "\
> +file://LICENSE;md5=d32239bcb673463ab874e80d47fae504 \
> +file://LICENSE.OpenSSL;md5=e39170c41c6f83de36426dbf49a03632 \
> +
> file://README;beginline=100;endline=124;md5=758a88cf2b27572df05996a3810066b3
> \
> +"
> +
> +DEPENDS = "\
> +libpcap \
> +ncurses \
> +"
> +
> +SRC_URI = "git://
> github.com/irontec/sngrep.git;protocol=https;branch=master"
> +SRCREV = "f7b36df3b79617892958b67cb4ad9313c6ce72d2"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit cmake pkgconfig
> +
> +PACKAGECONFIG ?= "\
> +openssl \
> +${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
> +unicode \
> +"
> +
> +PACKAGECONFIG[openssl] = "-DWITH_OPENSSL=ON,-DWITH_OPENSSL=OFF,openssl"
> +PACKAGECONFIG[gnutls] = "-DWITH_GNUTLS=ON,-DWITH_GNUTLS=OFF,gnutls
> libgcrypt"
> +PACKAGECONFIG[pcre] = "-DWITH_PCRE=OFF,-DWITH_PCRE=OFF,libpcre"
> +PACKAGECONFIG[zlib] = "-DWITH_ZLIB=ON,-DWITH_ZLIB=OFF,zlib"
> +PACKAGECONFIG[unicode] = "-DWITH_UNICODE=ON,-DWITH_UNICODE=OFF"
> +PACKAGECONFIG[ipv6] = "-DUSE_IPV6=ON,-DUSE_IPV6=OFF"
> +PACKAGECONFIG[eep] = "-DUSE_EEP=ON,-DUSE_EEP=OFF"
> --
> 2.34.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197099):
https://lists.openembedded.org/g/openembedded-core/message/197099
Mute This Topic: https://lists.openembedded.org/mt/104914270/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
* it's enabled for patches in oe-core for very long time and I was using
it for many other layers as well, so most layers should be in good
shape
* it's also possible to disable it for individual layer as shown
by oe-core in:
https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
Signed-off-by: Martin Jansa
---
meta/classes-global/insane.bbclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index e963001d09..9350bfa106 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -45,11 +45,10 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch
pkgconfig la \
already-stripped installed-vs-shipped ldflags compile-host-path \
install-host-path pn-overrides unknown-configure-option \
useless-rpaths rpaths staticdev empty-dirs \
-patch-fuzz \
+patch-fuzz patch-status \
"
# Add usrmerge QA check based on distro feature
ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
usrmerge', '', d)}"
-ERROR_QA:append:layer-core = " patch-status"
WARN_QA:append:layer-core = " missing-metadata missing-maintainer"
FAKEROOT_QA = "host-user-contaminated"
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197098):
https://lists.openembedded.org/g/openembedded-core/message/197098
Mute This Topic: https://lists.openembedded.org/mt/104922136/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
