On Tue, May 7, 2024 at 4:50 PM Ralph Siemsen via
lists.openembedded.org
wrote:
>
> On Fri, May 3, 2024 at 1:36 PM Steve Sakoman wrote:
> >
> > Please submit a kirkstone patch once this hits the master branch.
I've just sent a patch for scarthgap, clean cherry-picked from mast
When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.
Signed-off-by: Ralph Siemsen
Signed-off-by: Richard Purdie
(cherry picked from co
On Fri, May 3, 2024 at 1:36 PM Steve Sakoman wrote:
>
> Please submit a kirkstone patch once this hits the master branch.
Ack. I have been checking daily on master and master-next, but so far
it does not seem to have been picked up.
It is a clean cherry-pick into kirkstone, so at least that
When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.
Signed-off-by: Ralph Siemsen
---
meta/classes-recipe/uboot-sign.bbclass | 2 +-
1
The CVE is in the io/fs package, which first appeared in go1.16.
Since dunfell is using go1.14, this issue does not apply.
CVE was fixed in fa2d41d0ca736f3ad6b200b2a4e134364e9acc59
Original code in b64202bc29b9c1cf0118878d1c0acc9cdb2308f6
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools
be executed."
[1] https://groups.google.com/g/golang-announce/c/TzIC9-t8Ytg/m/IWz5T6x7AAAJ
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/go/go-1.14.inc
b/meta/recipes-devtools/go/go-1.14.inc
index
This is a bug in golang.org/x/net/html/parse.go. The golang compiler
includes a partial copy of this under src/vendor/golang.org/x/net/
however the "html" subdirectory is not included. So this bug does not
apply to the compiler itself.
Signed-off-by: Ralph Siemsen
---
meta/recipes-d
ining completely invalid names or an empty filename argument.
[1] https://groups.google.com/g/golang-announce/c/0fM21h43arc
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/go/go-1.14.inc
b/meta/recipes-dev
The issue only affects Windows per the golang announcement [1]:
On Windows, the filepath.Clean function could convert an invalid path to
a valid, absolute path. For example, Clean(`.\c:`) returned `c:`.
[1] https://groups.google.com/g/golang-announce/c/TzIC9-t8Ytg
Signed-off-by: Ralph Siemsen
Upstream-Status: Backport
[https://github.com/golang/go/commit/7139e8b024604ab168b51b99c6e8168257a5bf58]
CVE: CVE-2022-28327
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2022-28327.patch | 36 +++
2 files
Upstream-Status: Backport
[https://github.com/golang/go/commit/2b65cde5868d8245ef8a0b8eba1e361440252d3b]
CVE: CVE-2022-24921
Signed-off-by: Ralph Siemsen
+Date: Wed, 2 Feb 2022 16:41:32 -0500
+Subject: [PATCH] regexp/syntax: reject very deeply nested regexps in Parse
+MIME-Version: 1.0
+Content
Upstream-Status: Backport
[https://github.com/golang/go/commit/58facfbe7db2fbb9afed794b281a70bdb12a60ae]
CVE: CVE-2022-28131
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2022-28131.patch | 104 ++
2 files
Upstream-Status: Backport
[https://github.com/golang/go/commit/df9ce19db6df32d94eae8760927bdfbc595433c3]
CVE: CVE-2021-33198
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2021-33198.patch | 113 ++
2 files
Upstream-Status: Backport
[https://github.com/golang/go/commit/31d60cda1f58b7558fc5725d2b9e4531655d980e]
CVE: CVE-2021-33195
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2021-33195.patch | 373 ++
2 files
Upstream-Status: Backport
[https://github.com/golang/go/commit/d0aebe3e74fe14799f97ddd3f01129697c6a290a]
CVE: CVE-2021-44716
Signed-off-by: Ralph Siemsen
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2021-44716.patch | 93 +++
2 files
Ping. Any thoughts on this change?
Regards,
Ralph
On Wed, Mar 30, 2022 at 10:58 AM Ralph Siemsen via
lists.openembedded.org
wrote:
>
> In case of an error during download or parse of NVD JSON files, the
> previously opened sqlite3 database should be closed. Also any pending
>
On Mon, May 2, 2022 at 9:23 AM Marta Rybczynska wrote:
>
> On Fri, Apr 29, 2022 at 5:53 PM Ralph Siemsen
> wrote:
>>
>> # Interval between CVE database updates, in seconds.
>> # Set to "0" to to force an update of the database.
>> CVE_DATABASE_UPDATE_I
Hi Marta,
This explains why the CVE database update seemed to happen far more
frequently than it should. Thanks for digging into it.
On Fri, Apr 29, 2022 at 2:32 AM Marta Rybczynska wrote:
>
> Add a new variable FORCE_CVE_DB_UPDATE allowing the user to force
> the database update, if the
Hi Davide,
On Fri, Apr 29, 2022 at 4:22 AM Davide Gardenal
wrote:
>
> My idea was to convert cve_check_write_rootfs_manifest to a handler listening
> for BuildCompleted but then if someone builds more than one image the output
> is broken.
Actually that is already the case, if one builds
On Wed, 2022-04-13 at 11:39 -1000, Steve Sakoman wrote:
> I did another experiment, where I disabled generation of the sha256
> entries in Release (by adding --no-sha256 to the apt-ftparchive
> command)
>
> As a result we get past this first hash mismatch in Release, but then
> get later hash
On Wed, Apr 13, 2022 at 2:19 PM Steve Sakoman wrote:
> Yes, and it appears they had a quite similar bug in the past!
>
> https://lists.debian.org/deity/2006/07/msg00074.html
Interesting find... though it seems that is in a different sha256
implementation than the one being used here
On Wed, Apr 13, 2022 at 12:41 PM Mike Crowe wrote:
>
> I believe that Ralph's reproduction of the test failure without the zlib
> patch was from a complete rebuild without anything coming from the sstate
> cache.
Yes, just confirming the above. I wanted to be certain there was
nothing left-over
On Tue, Apr 12, 2022 at 5:49 PM Steve Sakoman wrote:
> I added a debug option to the failing command and did another autobuilder run.
>
> You can see the output here:
>
> https://errors.yoctoproject.org/Errors/Details/654608/
Okay, same error, "Hash Sum mismatch". And if I squint between all
On Mon, Apr 11, 2022 at 10:12 PM Steve Sakoman wrote:
> What distro is your build machine? On the autobuilder it is using a non
> debian distro for the debian build.
>
> My build machine is Ubuntu, so that is a major difference!
My build was also done on Ubuntu.
I have just completed a build
On Mon, Apr 11, 2022 at 6:43 PM Steve Sakoman wrote:
>
> I was using qemux86-64 for my experiment, so I guess I need to redo it
> now using the correct machine!
I have rebuild with MACHINE=qemux86. Same result, all tests appear to pass:
RESULTS - apt.AptRepoTest.test_apt_install_from_repo:
On Mon, Apr 11, 2022 at 2:58 PM Steve Sakoman wrote:
> Let me know if you make any progress!
After a clean build, and messing about with VNC, I am now able to
'bitbake core-image-sato:do_testimage'.
> Yes, either change will trigger the error. Without the zlib or xz
> patches all is fine.
On Mon, Apr 11, 2022 at 1:52 PM Steve Sakoman wrote:
> I see from irc that you've discovered INHERIT += "testimage". I think
> that might help with the above issue.
Indeed, I added that, which solved the missing do_testimage problem.
However even after rebuilding core-image sato, I do not have
On Mon, Apr 4, 2022 at 11:22 AM Steve Sakoman wrote:
> > Unfortunately this triggers other errors too :-(
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/4987
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/4949
Both of these seem to fail in
zgrep applied to a crafted file name with two or more newlines
can no longer overwrite an arbitrary, attacker-selected file.
Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=dc9740df61e575e8c3148b7bd3c147a81ea00c7c]
CVE: CVE-2022-1271
Signed-off-by: Ralph Siemsen
Malicious filenames can make xzgrep to write to arbitrary files
or (with a GNU sed extension) lead to arbitrary code execution.
Upstream-Status: Backport [https://tukaani.org/xz/xzgrep-ZDI-CAN-16587.patch]
CVE: CVE-2022-1271
Signed-off-by: Ralph Siemsen
---
.../xz/xz/CVE-2022-1271.patch
This includes a fix for CVE-2022-1271.
The existing "wrong path" patch needed to be refreshed, because the
context changed due to the following upstream change:
https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=31193bbd13cd2807d8ccaa2ba5b072303d5425e7
Signed-off-by: Ral
Malicious filenames can make xzgrep to write to arbitrary files
or (with a GNU sed extension) lead to arbitrary code execution.
Upstream-Status: Backport [https://tukaani.org/xz/xzgrep-ZDI-CAN-16587.patch]
CVE: CVE-2022-1271
Signed-off-by: Ralph Siemsen
---
.../xz/xz/CVE-2022-1271.patch
Sorry, please ignore this patch... it is already queued in
stable/dunfell-nut branch.
Regards,
Ralph
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164115):
https://lists.openembedded.org/g/openembedded-core/message/164115
Mute This Topic:
-by: Richard Purdie
Signed-off-by: Ralph Siemsen
---
meta/recipes-support/vim/vim.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index b3c471225e..5f01fc3bca 100644
--- a/meta/recipes-support/vim/vim.inc
The code shall check if the prepare writes would append more the
+allowed maximum attribute length.
+
+Fixes https://github.com/bluez/bluez/security/advisories/GHSA-479m-xcq5-9g2q
+
+Upstream-Status: Backport
[https://github.com/bluez/bluez/commit/591c546c536b42bef696d027f64aa22434f8c3f0]
+Signed-o
Yep, I must have fumbled it before sending it out.
Please ignore this one, I'll do a v2 later.
Any comments on the usefulness/format of the "Status in other
branches" would be appreciated.
Ralph
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online
ed maximum attribute length.
+
+Fixes https://github.com/bluez/bluez/security/advisories/GHSA-479m-xcq5-9g2q
+
+Upstream-Status: Backport
[https://github.com/bluez/bluez/commit/591c546c536b42bef696d027f64aa22434f8c3f0]
+Signed-off-by: Ralph Siemsen
+CVE: CVE-2022-0204
+
+---
+ src/share
Security Fixes
The rules for acceptance of records into the cache have been tightened
to prevent the possibility of poisoning if forwarders send records
outside the configured bailiwick. (CVE-2021-25220)
License-Update: copyright years
Signed-off-by: Ralph Siemsen
---
.../bind/{bind_9.11.36
connection to fail.
So instead of doing "return" to bail out early, instead "break" out of
the loop. The existing conn.commit() and conn.close() will be called.
Signed-off-by: Ralph Siemsen
---
I'm not entirely confident in this, would appreciate a review by folks
more knowledgeab
The fix for the CVE in 2.9.13 caused a regression which
was addressed after 2.9.13. We import that patch here.
Signed-off-by: Ralph Siemsen
---
.../CVE-2022-23308-fix-regression.patch | 98 +++
meta/recipes-core/libxml/libxml2_2.9.10.bb| 1 +
2 files changed, 99
On Sat, Mar 19, 2022 at 8:26 PM Richard Purdie
wrote:
>
> Posted as an RFC to see what people think of this. I make no claims
> on how useful it is/isn't but wanted to show integration isn't difficult
> and provide some inspiration for ideas.
>
> Details on the tool in question:
* Fixed a bug in the BN_mod_sqrt() function that can cause it to loop
foreverfor non-prime moduli ([CVE-2022-0778])
Signed-off-by: Ralph Siemsen
---
.../openssl/openssl/CVE-2022-0778.patch | 71 +++
.../openssl/openssl_1.1.1l.bb | 1 +
2 files changed, 72
Hi Steve
Somehow despite watching for replies, I managed to miss them until now.
On Wed, Mar 16, 2022 at 5:50 PM Steve Sakoman wrote:
>
> Sigh, now I remember why we did the CVE only patch - this version
> update introduces a ptest regression. It's sad I can't remember things
> from just a
;f=CHANGES;hb=refs/heads/OpenSSL_1_1_1-stable
[2]
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=e9e726506cd2a3fd9c0f12daf8cc1fe934c7dddb
Signed-off-by: Ralph Siemsen
---
.../openssl/openssl/CVE-2021-4160.patch | 145 --
.../{openssl_1.1.1l.bb => openssl_1.1.1n
Hi Richard,
On Sat, Mar 12, 2022 at 9:04 AM Richard Purdie
wrote:
>
> On Sat, 2022-03-12 at 09:19 +, Richard Purdie via lists.openembedded.org
> >
> > One of the patches is upstream, the other isn't. I can't see any patch
> > adding
> > pkg-config support to libxml.m4?
Thank you for
Use-after-free of ID and IDREF attributes, which could result in denial
of service.
https://nvd.nist.gov/vuln/detail/CVE-2022-23308
CVE: CVE-2022-23308
Signed-off-by: Ralph Siemsen
---
.../libxml/libxml2/CVE-2022-23308.patch | 204 ++
meta/recipes-core/libxml
. Post-decompression tarballs are
identical, so there is no change to the libxml2 code.
Signed-off-by: Ralph Siemsen
---
meta/recipes-core/libxml/libxml2_2.9.12.bb | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/libxml/libxml2_2.9.12.bb
b/meta
all I can say is that it compiles and seems to
work in some light testing. Perhaps others could help test it.
--
2.25.1
Ralph Siemsen (2):
libxml2: move to gitlab.gnome.org
libxml2: update to 2.9.13
.../0002-Work-around-lxml-API-abuse.patch | 213
.../libxml2/lib
- new version includes fix for CVE-2022-23308
- drop two patches which are upstream
Signed-off-by: Ralph Siemsen
---
.../0002-Work-around-lxml-API-abuse.patch | 213
.../libxml2/libxml-m4-use-pkgconfig.patch | 229 --
.../{libxml2_2.9.12.bb
On Thu, Mar 10, 2022 at 9:34 PM Steve Sakoman wrote:
>
> This passed a-full on the autobuilder:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3347
>
> So I'll be including this in my final pull request for the 3.1.15 release..
That's great, thank you.
Note that this is
#2899]
Signed-off-by: Ralph Siemsen
--
Changes from v1:
- commit message format adjusted to match previous updates
.../bind/{bind_9.11.35.bb => bind_9.11.36.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/bind/{bind_9.11.35
-by: Ralph Siemsen
---
.../bind/{bind_9.11.35.bb => bind_9.11.36.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/bind/{bind_9.11.35.bb => bind_9.11.36.bb}
(98%)
diff --git a/meta/recipes-connectivity/bind/bind_9.11.35.bb
b/meta/r
some more, but for now, it seems an improvement.
Tested-by: Ralph Siemsen
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162227):
https://lists.openembedded.org/g/openembedded-core/message/162227
Mute This Topic: https://lists.openembedded.org/m
On Tue, Feb 22, 2022 at 06:01:00PM +0100, Konrad Weihmann wrote:
This is somehow expected from my side tbh - as the lock file disables
any kind of parallelism - so just one instance of cve-check-task can
run at a time.
That likely explains why the loadavg is only around 1 during cve-check.
Hi Konrad,
On Fri, Jan 7, 2022 at 4:59 AM Konrad Weihmann
wrote:
> On 07.01.22 10:48, Konrad Weihmann wrote:
> > this should prevent running into the very rare error
> > sqlite3.OperationalError: attempt to write a readonly database
>
> It's also possible that check_same_thread (that defaults
to package name)
for filtering CVEs. The syntax for this is:
CVE_PRODUCT = "vendor:package"
When not specified, the vendor defaults to "%" which matches anything.
Signed-off-by: Ralph Siemsen
---
meta/recipes-extended/tar/tar_1.34.bb | 5 +++--
1 file changed, 3 insertions(
This CVE is fixed in the upstream glibc-2.31 branch, and dunfell already
includes an update to this version in commit e1e89ff7d75c3d22 ("glibc:
update to lastest 2.31 release HEAD")
Signed-off-by: Ralph Siemsen
---
meta/recipes-core/glibc/glibc_2.31.bb | 10 ++
1 file c
On Sun, Aug 08, 2021 at 04:33:59AM -1000, Steve Sakoman wrote:
Branch: dunfell
New this week: 3 CVEs
CVE-2021-28966: ruby:ruby-native
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-28966 *
CVE-2021-31810: ruby:ruby-native
PACKAGE_CLASES should be PACKAGE_CLASSES.
Signed-off-by: Ralph Siemsen
---
meta/lib/oeqa/manual/toaster-managed-mode.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/manual/toaster-managed-mode.json
b/meta/lib/oeqa/manual/toaster-managed-mode.json
and return if no meta data is present
Also quit if the length of the array after splitting is less than 6
Seems to work fine here. Thanks for the quick action.
Tested-by: Ralph Siemsen
Signed-off-by: Konrad Weihmann
---
v2: handle the case where key is set but value is none and
if resulting
not be the proper solution.
Regards,
Ralph
Signed-off-by: Ralph Siemsen
--
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index f27ade40db..c38f16afac 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core
In the generated cve.log files, include the epoch in the product
version. This better matches how versions are displayed elsewhere,
in particular the bb.warn("Found unpatched CVE...") that appears
on the terminal when CVEs are found.
Signed-off-by: Ralph Siemsen
---
Hopefully this is t
There is a "regression" of sorts when building initramfs with Yocto,
for kernel version 4.10 and later. Am looking for some suggestions on
how best to handle this.
In a nutshell, the behaviour is:
* kernel 4.9 and earlier: initramfs will be compressed, as long as at
least one decompressor
63 matches
Mail list logo
