Re: [OE-core][kirkstone][PATCH] xz: Update LICENSE variable for xz packages
On Mon, 6 May 2024, 13:09 nikhil via lists.openembedded.org, wrote:
> Update LICENSE defined for xz packages to match the license
> information provided in the xz COPYING file.
>
> The License information from PACKAGERS file of xz mentions
> packages with lzma files are in public domain.They ask to
> use GPLv2+, if only it's not possible to mention "PD and GPLv2+".
>
> Include PD license with GPLv2 to packages with lzma content:
> xz-dev package contains lzma header
> xz-doc package contains lzma man pages
> xz packages contains lzma binaries
>
> Links: https://github.com/tukaani-project/xz/blob/v5.2.6/COPYING
>https://github.com/tukaani-project/xz/blob/v5.4.1/PACKAGERS
>
> Signed-off-by: Bhabu Bindu
> ---
> meta/recipes-extended/xz/xz_5.2.6.bb | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-extended/xz/xz_5.2.6.bb
> b/meta/recipes-extended/xz/xz_5.2.6.bb
> index 3482622471..33496748bc 100644
> --- a/meta/recipes-extended/xz/xz_5.2.6.bb
> +++ b/meta/recipes-extended/xz/xz_5.2.6.bb
> @@ -9,10 +9,10 @@ SECTION = "base"
> # libgnu, which appears to be used for DOS builds. So we're left with
> # GPL-2.0-or-later and PD.
> LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception &
> LGPL-2.1-or-later & PD"
> -LICENSE:${PN} = "GPL-2.0-or-later"
> -LICENSE:${PN}-dev = "GPL-2.0-or-later"
> +LICENSE:${PN} = "PD & GPL-2.0-or-later"
> +LICENSE:${PN}-dev = "PD & GPL-2.0-or-later"
> LICENSE:${PN}-staticdev = "GPL-2.0-or-later"
> -LICENSE:${PN}-doc = "GPL-2.0-or-later"
> +LICENSE:${PN}-doc = "PD & GPL-2.0-or-later"
> LICENSE:${PN}-dbg = "GPL-2.0-or-later"
> LICENSE:${PN}-locale = "GPL-2.0-or-later"
> LICENSE:liblzma = "PD"
> --
> 2.25.1
>
I'm not a copyright lawyer, but from what I understand public domain is not
a licence. For a discussion see
https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
The next version of xz will be 0BSD so the statement will change too.
Regards,
Marta
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199047):
https://lists.openembedded.org/g/openembedded-core/message/199047
Mute This Topic: https://lists.openembedded.org/mt/105937026/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 02/12] linux-yocto/6.6: update CVE exclusions (6.6.24)
Hello Bruce et al,
For information, the linux_kernel_cves repo has now a banner "This
repository has been archived by the owner on May 2, 2024. It is now
read-only. ",
so I guess this is the last update.
Greg has scripting for statistics of the new process, haven't looked
into them yet.
Regards,
Marta
On Fri, May 3, 2024 at 4:40 AM Bruce Ashfield via
lists.openembedded.org
wrote:
>
> From: Bruce Ashfield
>
> Data pulled from: https://github.com/nluedtke/linux_kernel_cves
>
> 1/1 [
> Author: Nicholas Luedtke
> Email: nicholas.lued...@uwalumni.com
> Subject: Update 25Feb24
> Date: Sun, 25 Feb 2024 07:03:08 -0500
>
> ]
>
> Signed-off-by: Bruce Ashfield
> ---
> meta/recipes-kernel/linux/cve-exclusion_6.6.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.6.inc
> b/meta/recipes-kernel/linux/cve-exclusion_6.6.inc
> index bb9ba49c48..133cab88a3 100644
> --- a/meta/recipes-kernel/linux/cve-exclusion_6.6.inc
> +++ b/meta/recipes-kernel/linux/cve-exclusion_6.6.inc
> @@ -1,9 +1,9 @@
>
> # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
> -# Generated at 2024-03-28 16:40:04.102652+00:00 for version 6.6.23
> +# Generated at 2024-04-04 03:23:25.421265+00:00 for version 6.6.24
>
> python check_kernel_cve_status_version() {
> -this_version = "6.6.23"
> +this_version = "6.6.24"
> kernel_version = d.getVar("LINUX_VERSION")
> if kernel_version != this_version:
> bb.warn("Kernel CVE status needs updating: generated for %s but
> kernel is %s" % (this_version, kernel_version))
> --
> 2.39.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198966):
https://lists.openembedded.org/g/openembedded-core/message/198966
Mute This Topic: https://lists.openembedded.org/mt/105881317/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OE-core and meta-openembedded: a vulnerability in HTTP servers
Details: https://kb.cert.org/vuls/id/421644 Affected (amongst others): nodejs, oghttp, nghttp2, Apache httpd, go Multiple CVEs have been issued. Quoting from the description: HTTP allows messages to include named fields in both header and trailer sections. These header and trailer fields are serialised as field blocks in HTTP/2, so that they can be transmitted in multiple fragments to the target implementation. Many HTTP/2 implementations do not properly limit or sanitize the amount of CONTINUATION frames sent within a single stream. An attacker that can send packets to a target server can send a stream of CONTINUATION frames that will not be appended to the header list in memory but will still be processed and decoded by the server or will be appended to the header list, causing an out of memory (OOM) crash. Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197943): https://lists.openembedded.org/g/openembedded-core/message/197943 Mute This Topic: https://lists.openembedded.org/mt/105317551/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 _WARNING_
On Sat, Mar 30, 2024 at 1:26 PM Richard Purdie wrote: > > On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: > > Absolutely confirm. DO NOT UPDATE > > > > Marta > > > > On Sat, 30 Mar 2024, 02:04 Mark Hatle, > > wrote: > > > I know this request is a week or so old.. > > > > > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been > > > compromised: > > > > > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > > > > > --Mark > > We're not going to. The upgrade was already dropped after it failed > build testing. I do wonder why it failed. > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 > > I've ensured the sources were removed from our mirrors too. It looks to me that the Autobuilder has actually seen a side-effect of the backdoor... Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197866): https://lists.openembedded.org/g/openembedded-core/message/197866 Mute This Topic: https://lists.openembedded.org/mt/105226831/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 _WARNING_
On Mon, Apr 1, 2024 at 9:02 PM Denys Dmytriyenko wrote: > > On Mon, Apr 01, 2024 at 11:42:51AM +0200, Fathi Boudra wrote: > > On Sat, 30 Mar 2024 at 17:18, Richard Purdie > > wrote: > > > > > > On Sat, 2024-03-30 at 14:06 +0100, Martin Jansa wrote: > > > > From what is publicly known it injected malicious code (through m4 > > > > macro using payload hidden in obfuscated compressed test file) into > > > > built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in > > > > sshd (when sshd is built with patch adding systemd notifications > > > > which brings liblzma dependency to sshd e.g. on debian and ubuntu > > > > based systems). > > > > > > > > The build systems which just built this xz version shouldn't be > > > > affected (as it won't be using the liblzma.so from the OE build on > > > > the host). > > > > > > > > This publicly known part should be OK for OE, but it's right to be > > > > worried about the other things which aren't known (not only from > > > > these guys or from xz project). > > > > > > I concur. > > > > > > It is worrying but I've kind of been expecting something like this for > > > a while unfortunately. > > > > > > We need to watch what is going on and act accordingly if/as anything > > > else becomes known. > > > > https://nvd.nist.gov/vuln/detail/CVE-2024-3094 > > > > Distros have downgraded to older releases, still trying to figure out > > which version to use. > > While 5.4.6 version we've upgraded to in February was not yet compromised, > it was already being taken over by Jia Tan, moving releases to controlled > subdomain of xz.tukaani.org hosted off of GitHub directly, preparing for the > malicious release of 5.6.0 and 5.6.1. So, we've pointed to GitHub location > accordingly: > > https://git.openembedded.org/openembedded-core/commit/?id=9cc6c809c154019afe3bf6e6d617eab640faa4d0 > https://git.openembedded.org/openembedded-core/commit/?id=5be69fc3ff6296411c736e5c7c9522d99c0be2c6 > > But GitHub has suspended the project and associated developer accounts. The > original maintainer has posted some details on this matter here: > > https://tukaani.org/xz-backdoor/ > > Again, 5.4.6 tarball wasn't compromised, but it is no longer accessible from > GitHub - should we revert back to 5.4.5 that was hosted on the original site? > Though it should be mirrored... > The repository is disabled by GitHub, and the recipe does not work from this end. We need to switch to the older mirror and to the last version that was present. There are other parts of the attack coming out each day, so we should know to which version we need to revert quite soon. Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197850): https://lists.openembedded.org/g/openembedded-core/message/197850 Mute This Topic: https://lists.openembedded.org/mt/105226831/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 _WARNING_
Absolutely confirm. DO NOT UPDATE Marta On Sat, 30 Mar 2024, 02:04 Mark Hatle, wrote: > I know this request is a week or so old.. > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been compromised: > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > --Mark > > On 3/14/24 8:40 AM, Richard Purdie wrote: > > 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 (#197648): https://lists.openembedded.org/g/openembedded-core/message/197648 Mute This Topic: https://lists.openembedded.org/mt/105226831/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] [yocto-security] OE-core CVE metrics for master on Sun 24 Mar 2024 01:00:01 AM HST
On Sun, Mar 24, 2024 at 3:11 PM Alexander Kanavin wrote: > > I’m getting slightly concerned, no new CVEs second week in a row? Did the > checker break? > I think you weren't there at the weekly meeting when we discussed that: it started around Feb 14th and I see that in my data (I have a daily report). To make the story short: NVD is close to 0 activity since mid-February and there is no communication for now on why, what are the reasons etc. The security community is concerned and there are multiple ideas: amending/replacing the database, there is an open letter in the works etc. >From our practical view there's no automated solutions we can implement right now. I have some ideas and it would be good to discuss them, the next weekly meeting might be a good occasion. Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197591): https://lists.openembedded.org/g/openembedded-core/message/197591 Mute This Topic: https://lists.openembedded.org/mt/105119670/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] [yocto-security] OE-core CVE metrics for master on Sun 24 Mar 2024 01:00:01 AM HST
On Sun, Mar 24, 2024 at 3:25 PM Rich Persaud wrote: > > https://www.darkreading.com/cybersecurity-operations/nist-vuln-database-downshifts-prompting-questions-about-its-future > > > Next week, vulnerability researchers will gather for the VulnCon conference > > in Raleigh, N.C., where an "NVD symposium" is on the agenda. Perhaps more > > details will emerge then. I'm following this closely. Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197590): https://lists.openembedded.org/g/openembedded-core/message/197590 Mute This Topic: https://lists.openembedded.org/mt/105119670/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] [yocto-security] OE-core CVE metrics for master on Sun 03 Mar 2024 01:00:01 AM HST
On Mon, Mar 4, 2024 at 1:29 PM Ross Burton wrote: > > On 3 Mar 2024, at 13:18, Peter Marko via lists.yoctoproject.org > wrote: > > > > I already mentioned this last week. > > https://lists.openembedded.org/g/openembedded-core/message/196199 > > > > I think that partial NVD DB update is not working properly as things which > > were corrected by NVD are still showing up in patchmetrics but not in email > > reports. > > I need to file a bug for this issue. If CPEs are updated then they only > reach an existing database if the CVE itself is updated, as a CPE change > alone isn’t enough to appear in the query we use. > > I’ve a branch that adds this second query to the fetcher but it is incredibly > slow (and you thought the current fetcher was slow?) and still isn’t 100% > accurate. NIST are aware of “limitations” with the new API… > > For accurate runs I do sadly recommend forcing a full fetch of the CVE data. > I second Ross that we're likely hitting that problem. We have discussed that with Ross before and there seems to be no workaround other than to download the whole database. Solutions I see: - always fetch the whole database - go back to the old legacy system with JSON dumps (which is still online) - have an "official" YP mirror of the database Probably a subject we could discuss at the today's call. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196632): https://lists.openembedded.org/g/openembedded-core/message/196632 Mute This Topic: https://lists.openembedded.org/mt/104701002/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] python3-spdx-tools: upgrade 0.8.1 -> 0.8.2
Changelog:
added optional encoding parameter for parsing files
fixed handling of the FilesAnalyzed field in Tag-Value format
fixed the validation of the DownloadLocation field
fixed the error handling while parsing license expressions
fixed output of timezone-sensitive datetimes
added code architecture documentation
Signed-off-by: Marta Rybczynska
---
...{python3-spdx-tools_0.8.1.bb => python3-spdx-tools_0.8.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-spdx-tools_0.8.1.bb =>
python3-spdx-tools_0.8.2.bb} (88%)
diff --git a/meta/recipes-devtools/python/python3-spdx-tools_0.8.1.bb
b/meta/recipes-devtools/python/python3-spdx-tools_0.8.2.bb
similarity index 88%
rename from meta/recipes-devtools/python/python3-spdx-tools_0.8.1.bb
rename to meta/recipes-devtools/python/python3-spdx-tools_0.8.2.bb
index f58a138430..53263ca032 100644
--- a/meta/recipes-devtools/python/python3-spdx-tools_0.8.1.bb
+++ b/meta/recipes-devtools/python/python3-spdx-tools_0.8.2.bb
@@ -4,7 +4,7 @@ HOMEPAGE = "https://github.com/spdx/tools-python;
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=dc7f21ccff0f672f2a7cd6f412ae627d"
-SRC_URI[sha256sum] =
"c83652cd65b5726058dcbdaab85839dbe484c43ea6f61046137516aa1b8428ae"
+SRC_URI[sha256sum] =
"aea4ac9c2c375e7f439b1cef5ff32ef34914c083de0f61e08ed67cd3d9deb2a9"
BBCLASSEXTEND = "native nativesdk"
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190081):
https://lists.openembedded.org/g/openembedded-core/message/190081
Mute This Topic: https://lists.openembedded.org/mt/102340946/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] python3-beartype: upgrade 0.16.2 -> 0.16.4
Changelog for 0.16.4 [1]:
In beartype.claw type-check PEP 526-compliant annotated variable
assignments in methods
Fix an inheritance regression introduced in 0.16.3
Changelog for 0.16.3 [2]:
Add hot reloading
Support root superclass validators
Forward reference issubclass() proxying
Readable forward reference exceptions
Class redecoration eliding
Documentation update
[1] https://github.com/beartype/beartype/releases/tag/v0.16.4
[2] https://github.com/beartype/beartype/releases/tag/v0.16.3
Signed-off-by: Marta Rybczynska
---
.../{python3-beartype_0.16.2.bb => python3-beartype_0.16.4.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-beartype_0.16.2.bb =>
python3-beartype_0.16.4.bb} (75%)
diff --git a/meta/recipes-devtools/python/python3-beartype_0.16.2.bb
b/meta/recipes-devtools/python/python3-beartype_0.16.4.bb
similarity index 75%
rename from meta/recipes-devtools/python/python3-beartype_0.16.2.bb
rename to meta/recipes-devtools/python/python3-beartype_0.16.4.bb
index 20a5b92c61..ad4462e0e2 100644
--- a/meta/recipes-devtools/python/python3-beartype_0.16.2.bb
+++ b/meta/recipes-devtools/python/python3-beartype_0.16.4.bb
@@ -4,7 +4,7 @@ HOMEPAGE = "https://beartype.readthedocs.io;
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=e40b52d8eb5553aa8f705cdd3f979d69"
-SRC_URI[sha256sum] =
"47ec1c8c3be3f999f4f9f829e8913f65926aa7e85b180d9ffd305dc78d3e7d7b"
+SRC_URI[sha256sum] =
"1ada89cf2d6eb30eb6e156eed2eb5493357782937910d74380918e53c2eae0bf"
inherit setuptools3 pypi
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190080):
https://lists.openembedded.org/g/openembedded-core/message/190080
Mute This Topic: https://lists.openembedded.org/mt/102340902/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: Patchtest results for [OE-core][PATCH] patchtest: shorten test result outputs
On Wed, Nov 1, 2023 at 6:31 AM Marta Rybczynska via lists.openembedded.org wrote: > > > > > On Wed, 1 Nov 2023, 11:48 Anuj Mittal, wrote: >> >> On Tue, 2023-10-31 at 19:33 -0700, Tim Orling wrote: >> > >> > >> > On Tue, Oct 31, 2023 at 7:26 PM Anuj Mittal >> > wrote: >> > > On Tue, 2023-10-31 at 14:20 +, Trevor Gamblin wrote: >> > > > Thank you for your submission. Patchtest identified one >> > > > or more issues with the patch. Please see the log below for >> > > > more information: >> > > > >> > > > --- >> > > > Testing patch /home/patchtest/share/mboxes/patchtest-shorten- >> > > > test- >> > > > result-outputs.patch >> > > > >> > > > FAIL: test CVE presence in commit message: A CVE tag should be >> > > > provided in the commit message with format: "CVE: CVE--" >> > > > (test_mbox.TestMbox.test_cve_presence_in_commit_message) >> > > >> > > Is this a requirement to have this in commit message in this >> > > format? I >> > > don't think this was being followed until now. A lot of patches >> > > seem to >> > > be failing this test as a result. >> > > >> > >> > >> > This was required when patchtest was running previously. It has been >> > ignored for a while now, but that does not mean we should not enforce >> > it. It should be documented as required. >> > >> > The tags allow for machines to parse the relevant info. Anything else >> > is purely random and chaos. >> >> The tag is already required to be present in the CVE patch itself which >> is/can be parsed by scripts which actually I think is a better way of >> detecting whether a CVE is patched rather than looking at commit >> messages. >> >> If having it in a specific format in commit message as well helps, >> sure. It shouldn't take time to add it but we seem to be adding too >> many rules ... >> > > (adding Steve) > > I agree with Anuj, and I do not remember seeing a rule to put the > CVE number in the commit message. We already have it in the > patch file name (recommended) and inside the patch file itself. > Those two places are enough in my opinion. In fact, it will likely > be there in the commit message (its title), so repeating it does > not make much logical sense. > > In fact, I have an update of the manual with more detailed information > on submitting CVE fixes and looking for a resolution of this question > to submit it :) > > Steve, does such additional tag in the commit message make it > easier for you? > Here is what I have for the documentation: https://lists.yoctoproject.org/g/docs/message/4544 Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189897): https://lists.openembedded.org/g/openembedded-core/message/189897 Mute This Topic: https://lists.openembedded.org/mt/102275009/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Patchtest results for [OE-core][PATCH] patchtest: shorten test result outputs
On Wed, 1 Nov 2023, 11:48 Anuj Mittal, wrote: > On Tue, 2023-10-31 at 19:33 -0700, Tim Orling wrote: > > > > > > On Tue, Oct 31, 2023 at 7:26 PM Anuj Mittal > > wrote: > > > On Tue, 2023-10-31 at 14:20 +, Trevor Gamblin wrote: > > > > Thank you for your submission. Patchtest identified one > > > > or more issues with the patch. Please see the log below for > > > > more information: > > > > > > > > --- > > > > Testing patch /home/patchtest/share/mboxes/patchtest-shorten- > > > > test- > > > > result-outputs.patch > > > > > > > > FAIL: test CVE presence in commit message: A CVE tag should be > > > > provided in the commit message with format: "CVE: CVE--" > > > > (test_mbox.TestMbox.test_cve_presence_in_commit_message) > > > > > > Is this a requirement to have this in commit message in this > > > format? I > > > don't think this was being followed until now. A lot of patches > > > seem to > > > be failing this test as a result. > > > > > > > > > This was required when patchtest was running previously. It has been > > ignored for a while now, but that does not mean we should not enforce > > it. It should be documented as required. > > > > The tags allow for machines to parse the relevant info. Anything else > > is purely random and chaos. > > The tag is already required to be present in the CVE patch itself which > is/can be parsed by scripts which actually I think is a better way of > detecting whether a CVE is patched rather than looking at commit > messages. > > If having it in a specific format in commit message as well helps, > sure. It shouldn't take time to add it but we seem to be adding too > many rules ... > > (adding Steve) I agree with Anuj, and I do not remember seeing a rule to put the CVE number in the commit message. We already have it in the patch file name (recommended) and inside the patch file itself. Those two places are enough in my opinion. In fact, it will likely be there in the commit message (its title), so repeating it does not make much logical sense. In fact, I have an update of the manual with more detailed information on submitting CVE fixes and looking for a resolution of this question to submit it :) Steve, does such additional tag in the commit message make it easier for you? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189896): https://lists.openembedded.org/g/openembedded-core/message/189896 Mute This Topic: https://lists.openembedded.org/mt/102275009/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC][OE-core 7/7] create-spdx-3.0: support for recipe spdx creation
From: Samantha Jalabert
Change functions and tasks to match the SPDX 3 model.
Signed-off-by: Samantha Jalabert
---
meta/classes/create-spdx-3.0.bbclass | 728 +--
1 file changed, 224 insertions(+), 504 deletions(-)
diff --git a/meta/classes/create-spdx-3.0.bbclass
b/meta/classes/create-spdx-3.0.bbclass
index b0aef80db1..ffe34969a8 100644
--- a/meta/classes/create-spdx-3.0.bbclass
+++ b/meta/classes/create-spdx-3.0.bbclass
@@ -11,7 +11,7 @@ DEPLOY_DIR_SPDX ??= "${DEPLOY_DIR}/spdx"
CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
-SPDXDIR ??= "${WORKDIR}/spdx"
+SPDXDIR ??= "${WORKDIR}/spdx-3.0"
SPDXDEPLOY = "${SPDXDIR}/deploy"
SPDXWORK = "${SPDXDIR}/work"
SPDXIMAGEWORK = "${SPDXDIR}/image-work"
@@ -64,21 +64,74 @@ def get_doc_namespace(d, doc):
namespace_uuid = uuid.uuid5(uuid.NAMESPACE_DNS,
d.getVar("SPDX_UUID_NAMESPACE"))
return "%s/%s-%s" % (d.getVar("SPDX_NAMESPACE_PREFIX"), doc.name,
str(uuid.uuid5(namespace_uuid, doc.name)))
-def create_annotation(d, comment):
+def generate_creationInfo(d, document):
+"""
+Generate the creationInfo and its elements for a document
+"""
from datetime import datetime, timezone
+import oe.spdx3
creation_time =
datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
-annotation = oe.spdx.SPDXAnnotation()
-annotation.annotationDate = creation_time
-annotation.annotationType = "OTHER"
-annotation.annotator = "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"),
d.getVar("SPDX_TOOL_VERSION"))
-annotation.comment = comment
-return annotation
+
+document.creationInfo = oe.spdx3.SPDX3CreationInfo()
+document.creationInfo.specVersion = "3.0.0"
+document.creationInfo.created = creation_time
+document.creationInfo.dataLicense = "https://spdx.org/licenses/CC0-1.0;
+
+tool = oe.spdx3.SPDX3Tool()
+tool.name = "OpenEmbedded Core create-spdx.bbclass"
+tool.spdxId = "spdx-" + d.getVar("PN") + ":SPDXRef-Actor-" +
tool.name.replace(" ", "")
+tool.creationInfo = document.creationInfo
+document.element.append(tool)
+document.creationInfo.createdUsing.append(tool)
+
+organization = oe.spdx3.SPDX3Organization()
+organization.name = d.getVar("SPDX_ORG")
+organization.spdxId = "spdx-" + d.getVar("PN") + ":SPDXRef-Actor-" +
organization.name.replace(" ", "")
+organization.creationInfo = document.creationInfo
+document.element.append(organization)
+document.creationInfo.createdBy.append(organization)
+
+person = oe.spdx3.SPDX3Person()
+person.name = "Person: N/A ()"
+person.spdxId = "spdx-" + d.getVar("PN") + ":SPDXRef-Actor-" +
person.name.replace(" ", "")
+document.creationInfo.createdBy.append(person)
+document.element.append(person)
+
+def get_supplier(d, doc=None):
+"""
+Get the supplier of a document or create it.
+"""
+import oe.spdx3
+
+supplier = d.getVar("SPDX_SUPPLIER")
+agentName = supplier.split(": ")[1]
+agentType = supplier.split(": ")[0]
+
+if doc:
+for element in doc.element:
+if(isinstance(element, oe.spdx3.SPDX3Agent) and element.name ==
agentName):
+return element
+
+if(agentType == "Organization"):
+agent = oe.spdx3.SPDX3Organization()
+elif(agentType == "Person"):
+agent = oe.spdx3.SPDX3Person()
+else:
+raise KeyError("%r is not a valid SPDX agent type" % agentType)
+
+agent.name = agentName
+agent.spdxId = "spdx-" + d.getVar("PN") + ":SPDXRef-Actor-" +
agent.name.replace(" ", "")
+agent.creationInfo = doc.creationInfo
+
+return agent
def recipe_spdx_is_native(d, recipe):
-return any(a.annotationType == "OTHER" and
- a.annotator == "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"),
d.getVar("SPDX_TOOL_VERSION")) and
- a.comment == "isNative" for a in recipe.annotations)
+return False
+# TODO: find a better way to mark native recipes
+#return any(a.annotationType == "OTHER" and
+# a.annotator == "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"),
d.getVar("SPDX_TOOL_VERSION")) and
+# a.comment == "isNative" for a in recipe.annotations)
def is_work_shared_spdx(d):
return bb.data.inherits_class('kernel', d) or ('work-shared' in
d.getVar('WORKDIR'))
@@ -113,7 +166,7 @@ def convert_license_to_spdx(lic, document, d, existing={}):
if name in extracted:
return
-extracted_info = oe.spdx.SPDXExtractedLicensingInfo()
+extracted_info = oe.spdx.SPDX3ExtractedLicensingInfo()
extracted_info.name = name
extracted_info.licenseId = ident
extracted_info.extractedText = None
@@ -202,8 +255,7 @@ def process_sources(d):
def add_package_files(d, doc, spdx_pkg, topdir, get_spdxid, get_types, *,
archive=None, ignore_dirs=[], ignore_top_level_dirs=[]):
from pathlib import Path
-import oe.spdx
-import hashlib
+import oe.spdx3
source_date_epoch =
[OE-core] [RFC][OE-core 6/7] README.SPDX3: add file
Add a specific readme for SPDX3 with open questions and other notes related to the PoC. Signed-off-by: Marta Rybczynska --- README.SPDX3 | 42 ++ 1 file changed, 42 insertions(+) create mode 100644 README.SPDX3 diff --git a/README.SPDX3 b/README.SPDX3 new file mode 100644 index 00..57f98756ab --- /dev/null +++ b/README.SPDX3 @@ -0,0 +1,42 @@ +This repository contains the Proof-of-Concept code for SPDX3 support +in the Yocto Project. + +What does the code include: +* The SPDX3 generation with JSON-LD serialization, still using .json extension +* Implementations of the core, and software profiles + +Here are the known limitations: +* At the time of writing this code, the SPDX3 specification is still undergoing + changes. Especially, the root element has not been yet decided. Because of + that, the code might require changes when the final specification is + released. + +* Some parts of the SPDX3 require clarifications. Current issues: + - Software.Package.homepage is sometiemes also called homePage: need to +confirm spelling + - Core.Relationship.from needs special care in Python as it conflicts +with a built-in + - should suppliedBy be serialized by an array or as a single string? + - In examples, SpdxDocument has an attribute namespace. It does not in the +documentation + - what is the equivalent of the documentNamespace that was in 2.2? + +* SPDX3 introduces modular model, where content depends on the profile used. + The configuration of profiles to generate needs to be reworked. Today, + generation is gated by variables shared with SPDX2.2 code like + SPDX_INCLUDE_SOURCES. In SPDX3 it could be done by enabling specific + profiles and variables like SPDX3_ENABLE_LICENSING or SPDX3_ENABLE_SECURITY. + +* The implementation includes data similar to the YP SPDX 2.2 content. SPDX 3.0 + has additional profiles and fields that did not exist in the earier version. + The project needs a discussion on what is useful to include in the YP SPDX. + Additional profiles and classes might be implemented to carry that data. + +* The security profile implementation has been prototyped. However, some part + of the needed data is necessary from the cve-check database (for example: + CVSS). Obtaining the information is possible, but will require dependency on + the cve-check to download the database, then refactoring of the cve-check + database accesses so that they can be done from other classes while keeping + correct locks. Also, VulnAssessmentRelationship requires classification + of fixes as "Fixed", "NotAffected", while YP cve-check has only one category + for both. At the moment of writing this, there is a patch on the ML. -- 2.42.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189717): https://lists.openembedded.org/g/openembedded-core/message/189717 Mute This Topic: https://lists.openembedded.org/mt/102197347/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC][OE-core 5/7] oe/sbom: search into json
From: Louis Rannou
Create a function that search into a json-ld instead of completely loading it.
Signed-off-by: Louis Rannou
---
meta/lib/oe/sbom.py | 32
1 file changed, 32 insertions(+)
diff --git a/meta/lib/oe/sbom.py b/meta/lib/oe/sbom.py
index 28db9cf719..21333c0a84 100644
--- a/meta/lib/oe/sbom.py
+++ b/meta/lib/oe/sbom.py
@@ -119,3 +119,35 @@ def read_doc(fn):
doc = oe.spdx.SPDXDocument.from_json(f)
return (doc, sha1.hexdigest())
+
+
+def search_doc(fn, attr_types=None):
+"""
+Look for all attributes in the given dictionary. Return the document
+element, a dictionary of the required attributes and the sha1 of the file.
+"""
+import hashlib
+import oe.spdx3
+import io
+import contextlib
+
+@contextlib.contextmanager
+def get_file():
+if isinstance(fn, io.IOBase):
+yield fn
+else:
+with fn.open("rb") as f:
+yield f
+
+with get_file() as f:
+sha1 = hashlib.sha1()
+while True:
+chunk = f.read(4096)
+if not chunk:
+break
+sha1.update(chunk)
+
+f.seek(0)
+doc, attributes = oe.spdx3.SPDX3SpdxDocument.from_json(f, attr_types
or [])
+
+return (doc, attributes, sha1.hexdigest())
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189716):
https://lists.openembedded.org/g/openembedded-core/message/189716
Mute This Topic: https://lists.openembedded.org/mt/102197345/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC][OE-core 4/7] create-spdx-3.0: SPDX3 objects as classes
From: Louis Rannou
Create SPDX3 objects that classes as they are described in the SPDX3 model.
Signed-off-by: Louis Rannou
Signed-off-by: Samantha Jalabert
---
meta/lib/oe/spdx3.py | 385 +++
1 file changed, 385 insertions(+)
create mode 100644 meta/lib/oe/spdx3.py
diff --git a/meta/lib/oe/spdx3.py b/meta/lib/oe/spdx3.py
new file mode 100644
index 00..ecbe999258
--- /dev/null
+++ b/meta/lib/oe/spdx3.py
@@ -0,0 +1,385 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+#
+# This library is intended to set the data types for the SPDX3 specification.
It
+# is not intended to encode any particular OE specific behaviors, see the
+# sbom.py for that.
+#
+
+from oe.spdx import _String, _StringList, _Object, _ObjectList
+from oe.spdx import SPDXObject
+
+import json
+import hashlib
+
+class SPDX3Tool(SPDXObject):
+pass
+
+class SPDX3Agent(SPDXObject):
+pass
+
+#
+# Profile: Core - Enumerations
+#
+SPDX3HashAlgorithm = [
+"blake2b256",
+"blake2b384",
+"blake2b512",
+"blake3",
+"crystalsKyber",
+"crystalsDilithium",
+"falcon",
+"md2",
+"md4",
+"md5",
+"md6",
+"other",
+"sha1",
+"sha224",
+"sha256",
+"sha3_224",
+"sha3_256",
+"sha3_384",
+"sha3_512",
+"sha384",
+"sha512",
+"spdxPvcSha1",
+"spdxPvcSha256",
+"sphincsPlus"
+]
+
+#
+# Profile: Core - Datatypes
+#
+
+class SPDX3IntegrityMethod(SPDXObject):
+comment = _String()
+
+class SPDX3Hash(SPDX3IntegrityMethod):
+hashValue = _String()
+algorithm = _String()
+
+#
+# Profile: Core - Classes
+#
+class SPDX3CreationInfo(SPDXObject):
+specVersion = _String(default="3.0.0")
+created = _String()
+createdBy = _ObjectList(SPDX3Agent)
+profile = _StringList(default=["core", "software"]) # TODO: not in
creationInfo in spec
+createdUsing = _ObjectList(SPDX3Tool)
+dataLicense = _String(default="CC0-1.0")
+
+def serializer(self):
+"""
+Serialize a creationInfo element.
+createdBy and createdUsing are only stored with their spdxId.
+other attributes are ordinary serialized
+"""
+main = {"type": self.__class__.__name__[len("SPDX3"):],
+"createdBy": []}
+
+main["createdBy"] = [c.spdxId for c in self._spdx["createdBy"]]
+if "createdUsing" in self._spdx and len(self._spdx["createdUsing"]):
+main["createdUsing"] = [c.spdxId for c in
self._spdx["createdUsing"]]
+
+for (key, value) in self._spdx.items():
+if not key in ["createdBy", "createdUsing"]:
+main.update({key: value})
+return main
+
+class SPDX3ExternalMap(SPDXObject):
+externalId = _String()
+verifiedUsing = _ObjectList(SPDX3IntegrityMethod)
+definingDocument = _String()
+
+class SPDX3Element(SPDXObject):
+spdxId = _String(default="SPDXRef-DOCUMENT")
+name = _String()
+summary = _String()
+description = _String()
+creationInfo = _String()
+verifiedUsing = _ObjectList(SPDX3IntegrityMethod)
+#packages = _ObjectList(SPDXPackage)
+#files = _ObjectList(SPDXFile)
+#relationships = _ObjectList(SPDXRelationship)
+#externalDocumentRefs = _ObjectList(SPDXExternalDocumentRef)
+#hasExtractedLicensingInfos = _ObjectList(SPDXExtractedLicensingInfo)
+
+def serializer(self, rootElement):
+"""
+Default serialization of an Element
+creationInfo is moved to the root and refered with its id
+context and element defined in ElementCollection and Bundle are ignored
+Element objects are ignored
+other attributes are ordinary serialized
+"""
+main = {"type": self.__class__.__name__[len("SPDX3"):]}
+
+for (key, value) in self._spdx.items():
+if key == "creationInfo":
+_id = rootElement.creationinfo(value)
+main["creationInfo"] = _id
+elif key not in ["context", "element"] \
+and not isinstance(value, SPDX3Element):
+if key[0] == '_':
+main.update({key[1:]: value})
+else:
+main.update({key: value})
+return main
+
+def add_relationship(self, _from, relationship, _to):
+if isinstance(_from, SPDX3Element):
+from_spdxid = _from.spdxId
+else:
+from_spdxid = _from
+
+if isinstance(_to, SPDX3Element):
+to_spdxid = _to.spdxId
+else:
+to_spdxid = _to
+
+for element in self.element:
+if isinstance(element, SPDX3Relationship) \
+and element._from == from_spdxid \
+and element.relationshipType == relationship:
+element.to.append(to_spdxid)
+return element.spdxId
+
+r = SPDX3Relationship(
+_from=from_spdxid,
+
[OE-core] [RFC][OE-core 3/7] oe/sbom: change the write_doc to prepare for spdx3
From: Louis Rannou
This changes the prototype of write_doc as the SPDX3 documentation does not
specify yet which is the root element.
Signed-off-by: Louis Rannou
Signed-off-by: Marta Rybczynska
Signed-off-by: Samantha Jalabert
---
meta/lib/oe/sbom.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oe/sbom.py b/meta/lib/oe/sbom.py
index 824839378a..28db9cf719 100644
--- a/meta/lib/oe/sbom.py
+++ b/meta/lib/oe/sbom.py
@@ -68,7 +68,8 @@ def doc_path(spdx_deploy, doc_name, arch, subdir):
return spdx_deploy / arch / subdir / (doc_name + ".spdx.json")
-def write_doc(d, spdx_doc, arch, subdir, spdx_deploy=None, indent=None):
+# WARNING: Changed for SPDX3
+def write_doc(d, spdx_graph, spdx_doc, arch, subdir, spdx_deploy=None,
indent=None):
from pathlib import Path
if spdx_deploy is None:
@@ -77,7 +78,7 @@ def write_doc(d, spdx_doc, arch, subdir, spdx_deploy=None,
indent=None):
dest = doc_path(spdx_deploy, spdx_doc.name, arch, subdir)
dest.parent.mkdir(exist_ok=True, parents=True)
with dest.open("wb") as f:
-doc_sha1 = spdx_doc.to_json(f, sort_keys=False, indent=indent)
+doc_sha1 = spdx_graph.to_json(f, sort_keys=False, indent=indent)
l = _doc_path_by_namespace(spdx_deploy, arch, spdx_doc.documentNamespace)
l.parent.mkdir(exist_ok=True, parents=True)
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189714):
https://lists.openembedded.org/g/openembedded-core/message/189714
Mute This Topic: https://lists.openembedded.org/mt/102197342/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC][OE-core 2/7] oe/spdx: extend spdx.py objects
From: Louis Rannou
Extend objects used to build the spdx scheme:
- add support for inheritance
- hide all attributes starting by _spdx
- add methods to list properties and item pairs
- improve the serializer to match the spdx3 scheme
Signed-off-by: Louis Rannou
---
meta/lib/oe/sbom.py | 2 +-
meta/lib/oe/spdx.py | 30 +++---
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/meta/lib/oe/sbom.py b/meta/lib/oe/sbom.py
index fd4b6895d8..824839378a 100644
--- a/meta/lib/oe/sbom.py
+++ b/meta/lib/oe/sbom.py
@@ -77,7 +77,7 @@ def write_doc(d, spdx_doc, arch, subdir, spdx_deploy=None,
indent=None):
dest = doc_path(spdx_deploy, spdx_doc.name, arch, subdir)
dest.parent.mkdir(exist_ok=True, parents=True)
with dest.open("wb") as f:
-doc_sha1 = spdx_doc.to_json(f, sort_keys=True, indent=indent)
+doc_sha1 = spdx_doc.to_json(f, sort_keys=False, indent=indent)
l = _doc_path_by_namespace(spdx_deploy, arch, spdx_doc.documentNamespace)
l.parent.mkdir(exist_ok=True, parents=True)
diff --git a/meta/lib/oe/spdx.py b/meta/lib/oe/spdx.py
index 7aaf2af5ed..97b9e011ad 100644
--- a/meta/lib/oe/spdx.py
+++ b/meta/lib/oe/spdx.py
@@ -145,9 +145,13 @@ class MetaSPDXObject(type):
def __new__(mcls, name, bases, attrs):
attrs["_properties"] = {}
-for key in attrs.keys():
-if isinstance(attrs[key], _Property):
-prop = attrs[key]
+at = {}
+for basecls in bases:
+at.update(basecls._properties)
+at.update(attrs)
+for key in at.keys():
+if isinstance(at[key], _Property):
+prop = at[key]
attrs["_properties"][key] = prop
prop.set_property(attrs, key)
@@ -166,15 +170,27 @@ class SPDXObject(metaclass=MetaSPDXObject):
if name in d:
self._spdx[name] = prop.init(d[name])
-def serializer(self):
-return self._spdx
-
def __setattr__(self, name, value):
-if name in self._properties or name == "_spdx":
+# All attributes must be in _properties or are hidden variables which
+# must be prefixed with _spdx
+if name in self._properties or name[:len("_spdx")] == "_spdx":
super().__setattr__(name, value)
return
raise KeyError("%r is not a valid SPDX property" % name)
+def properties(self):
+return self._properties.keys()
+
+def items(self):
+return self._properties.items()
+
+def serializer(self, rootElement):
+main = {"type": self.__class__.__name__[len("SPDX3"):]}
+for (key, value) in self._spdx.items():
+if key[0] == '_':
+key = key[1:]
+main.update({key: value})
+return main
#
# These are the SPDX objects implemented from the spec. The *only* properties
# that can be added to these objects are ones directly specified in the SPDX
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189713):
https://lists.openembedded.org/g/openembedded-core/message/189713
Mute This Topic: https://lists.openembedded.org/mt/102197341/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC][OE-core 1/7] create-spdx-3.0: copy 2.2 class
From: Louis Rannou
Initialize the work on SPDX 3 with a copy of the SPDX 2.2. Change default to
SPDX 3.
Signed-off-by: Louis Rannou
Signed-off-by: Marta Rybczynska
---
meta/classes/create-spdx-3.0.bbclass | 1158 ++
meta/classes/create-spdx.bbclass |2 +-
2 files changed, 1159 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/create-spdx-3.0.bbclass
diff --git a/meta/classes/create-spdx-3.0.bbclass
b/meta/classes/create-spdx-3.0.bbclass
new file mode 100644
index 00..b0aef80db1
--- /dev/null
+++ b/meta/classes/create-spdx-3.0.bbclass
@@ -0,0 +1,1158 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+DEPLOY_DIR_SPDX ??= "${DEPLOY_DIR}/spdx"
+
+# The product name that the CVE database uses. Defaults to BPN, but may need
to
+# be overriden per recipe (for example tiff.bb sets CVE_PRODUCT=libtiff).
+CVE_PRODUCT ??= "${BPN}"
+CVE_VERSION ??= "${PV}"
+
+SPDXDIR ??= "${WORKDIR}/spdx"
+SPDXDEPLOY = "${SPDXDIR}/deploy"
+SPDXWORK = "${SPDXDIR}/work"
+SPDXIMAGEWORK = "${SPDXDIR}/image-work"
+SPDXSDKWORK = "${SPDXDIR}/sdk-work"
+SPDXDEPS = "${SPDXDIR}/deps.json"
+
+SPDX_TOOL_NAME ??= "oe-spdx-creator"
+SPDX_TOOL_VERSION ??= "1.0"
+
+SPDXRUNTIMEDEPLOY = "${SPDXDIR}/runtime-deploy"
+
+SPDX_INCLUDE_SOURCES ??= "0"
+SPDX_ARCHIVE_SOURCES ??= "0"
+SPDX_ARCHIVE_PACKAGED ??= "0"
+
+SPDX_UUID_NAMESPACE ??= "sbom.openembedded.org"
+SPDX_NAMESPACE_PREFIX ??= "http://spdx.org/spdxdoc;
+SPDX_PRETTY ??= "0"
+
+SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
+
+SPDX_CUSTOM_ANNOTATION_VARS ??= ""
+
+SPDX_ORG ??= "OpenEmbedded ()"
+SPDX_SUPPLIER ??= "Organization: ${SPDX_ORG}"
+SPDX_SUPPLIER[doc] = "The SPDX PackageSupplier field for SPDX packages created
from \
+this recipe. For SPDX documents create using this class during the build,
this \
+is the contact information for the person or organization who is doing the
\
+build."
+
+def extract_licenses(filename):
+import re
+
+lic_regex = re.compile(rb'^\W*SPDX-License-Identifier:\s*([
\w\d.()+-]+?)(?:\s+\W*)?$', re.MULTILINE)
+
+try:
+with open(filename, 'rb') as f:
+size = min(15000, os.stat(filename).st_size)
+txt = f.read(size)
+licenses = re.findall(lic_regex, txt)
+if licenses:
+ascii_licenses = [lic.decode('ascii') for lic in licenses]
+return ascii_licenses
+except Exception as e:
+bb.warn(f"Exception reading {filename}: {e}")
+return None
+
+def get_doc_namespace(d, doc):
+import uuid
+namespace_uuid = uuid.uuid5(uuid.NAMESPACE_DNS,
d.getVar("SPDX_UUID_NAMESPACE"))
+return "%s/%s-%s" % (d.getVar("SPDX_NAMESPACE_PREFIX"), doc.name,
str(uuid.uuid5(namespace_uuid, doc.name)))
+
+def create_annotation(d, comment):
+from datetime import datetime, timezone
+
+creation_time =
datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
+annotation = oe.spdx.SPDXAnnotation()
+annotation.annotationDate = creation_time
+annotation.annotationType = "OTHER"
+annotation.annotator = "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"),
d.getVar("SPDX_TOOL_VERSION"))
+annotation.comment = comment
+return annotation
+
+def recipe_spdx_is_native(d, recipe):
+return any(a.annotationType == "OTHER" and
+ a.annotator == "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"),
d.getVar("SPDX_TOOL_VERSION")) and
+ a.comment == "isNative" for a in recipe.annotations)
+
+def is_work_shared_spdx(d):
+return bb.data.inherits_class('kernel', d) or ('work-shared' in
d.getVar('WORKDIR'))
+
+def get_json_indent(d):
+if d.getVar("SPDX_PRETTY") == "1":
+return 2
+return None
+
+python() {
+import json
+if d.getVar("SPDX_LICENSE_DATA"):
+return
+
+with open(d.getVar("SPDX_LICENSES"), "r") as f:
+data = json.load(f)
+# Transform the license array to a dictionary
+data["licenses"] = {l["licenseId"]: l for l in data["licenses"]}
+d.setVar("SPDX_LICENSE_DATA", data)
+}
+
+def convert_license_to_spdx(lic, document, d, existing={}):
+from pathlib import Path
+import oe.spdx
+
+license_data = d.getVar("SPDX_LICENSE_DATA")
+extracted = {}
+
+def add_extracted_license(ident, name):
+nonlocal document
+
+if name in extracted:
+return
+
+extracted_info = oe.spdx.SPDXExtractedLicensingInfo()
+extracted_info.n
[OE-core] [RFC][OE-core 0/7] SPDX3 Proof-of-Concept
This patch-set adds a proof-of-concept implementation of the upcoming SPDX3 standard to the SBOM generation of the Yocto Project/OpenEmbedded. The current code delivers an equivalent of what is produced for SPDX2.2. The standard has not been released yet, and there is some specification work in progress still. Our questions and open points are available in the README.SPDX3 file. Also, this first RFC delivery will be followed by another one with SPDX assembly and the Licensing profile. Louis Rannou (5): create-spdx-3.0: copy 2.2 class oe/spdx: extend spdx.py objects oe/sbom: change the write_doc to prepare for spdx3 create-spdx-3.0: SPDX3 objects as classes oe/sbom: search into json Marta Rybczynska (1): README.SPDX3: add file Samantha Jalabert (1): create-spdx-3.0: support for recipe spdx creation README.SPDX3 | 42 ++ meta/classes/create-spdx-3.0.bbclass | 878 +++ meta/classes/create-spdx.bbclass | 2 +- meta/lib/oe/sbom.py | 37 +- meta/lib/oe/spdx.py | 30 +- meta/lib/oe/spdx3.py | 385 6 files changed, 1364 insertions(+), 10 deletions(-) create mode 100644 README.SPDX3 create mode 100644 meta/classes/create-spdx-3.0.bbclass create mode 100644 meta/lib/oe/spdx3.py -- 2.42.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189711): https://lists.openembedded.org/g/openembedded-core/message/189711 Mute This Topic: https://lists.openembedded.org/mt/102197338/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] cve-check: Classify patched CVEs into 3 statuses
Hello Marko, I think that we will need to go back to the drawing board and have a look what we want to report from the CVE check. I'm not totally happy with the solution proposed here, because it is adding high-level states. However, it is a step forward to be able to map our status to VEX. In the RFQ work on SPDX3 (which includes VEX in the "security" profile) we had a look at that and realized that mapping of the information is not possible, we're missing information. The current state of "Ignore" is not great either. You have added additional context, but still some statuses do not make sense in Ignore. It is effectively used as an "override" of everything. I also have a multi-fetcher in the works, which downloads CVE data from other sources that NVD. Results are sometimes in conflict and we'll have to handle that too. And there are other sources lurking behind too. So, when the RFQ season is finished (Oct 31st), we'll get back to the drawing board to design what statuses we really want and need. I understand you'd like to be a part of this discussion. Kind regards, Marta On Wed, Oct 25, 2023 at 3:09 PM Marko, Peter wrote: > > Hello Marta, > > > > Major reason why we introduced CVE_STATUS was exactly to avoid patch like > this. > > There were ideas to introduce 5 or 10 or 15 different statuses and we decided > to keep 3 and introduce “sub-statuses”. > > These sub-statuses are listed in cve reports, too. > > > > Currently we have three main statuses: > > Patched – common status for all sub-statuses which indicate that component is > not vulnerable > > Unpatched - common status for all sub-statuses which indicate that component > is vulnerable > > Ignored - common status for all sub-statuses which indicate that component is > vulnerable but not in yocto configuration context > > > > If we don’t like “Patched” we can rename it (e.g. to “Unaffected”) and have > additional sub-statuses under this new name. > > Otherwise we start exploding the statuses as someone will “need” additional > one soon. > > > > If we really want to introduce these new statues (I hope not), please modify > this patch to handle its CVE_STATUS flags, too. > > Additionally, I’d drop “Undecidable” and map it to “Unpatched” (so someone > needs to analyze as any other open vulnerability report) > > > > Best Regards, > > Peter > > > > From: Marta Rybczynska > Sent: Wednesday, October 25, 2023 14:44 > To: Andrej Valek > Cc: Matsunaga-Shinji ; Richard Purdie > ; OE-core > ; Shunsuke Tokumoto > ; Marko, Peter (ADV D EU SK BFS1) > > Subject: Re: [OE-core] [PATCH v2] cve-check: Classify patched CVEs into 3 > statuses > > > > Hello Andrej, > > This patch is splitting the Patched state, not the ignore one. This is not > incorrect CPE or anything else. > > > > Currently Patched means one of two situations: either this issue has never > affected the code base (example: we have version 1.0, issue was introduced in > 2.0 and fixed in 2.1), or the issue has been fixed. > > > > Yes, another reason to say ignore, not affected is a manual analysis showing > a thing like: the issue affects only windows. > > > > Regards, > > Marta > > > > On Wed, 25 Oct 2023, 12:18 Andrej Valek, wrote: > > Hi Marta, > > That's fine, as I said we designed the "ignore" with status > "cpe-incorrect" or "ignored" exactly for those purposes. Extending the > option with "not affected" doesn't make any sense. > > You have to set the status to "why is not affected" = "ignored". Which > completely covers the requested case. > > Regards, > Andrej > > On 25.10.2023 11:33, Marta Rybczynska wrote: > > Hi Andrej, > > This is more complex. "Not affected" is also an issue that isn't present in > > the > > code - like when we have a version that has never had the vulnerability. > > Those are also currently 'Patched' in cve-check. > > > > This work is in sync with what VEX is doing, is it the use-case > > Matsanaga-Shinji? > > > > Regards, > > Marta > > > > On Wed, Oct 25, 2023 at 8:44 AM Andrej Valek wrote: > >> Hi all, > >> > >> Do we really need a new "not_affected" state? I guess the ignore state > >> is exactly designed for those purposes. > >> > >> Regards, > >> Andrej > >> > >> On 25.10.2023 07:13, Matsunaga-Shinji wrote: > >>> CVEs that are currently considered "Patched" are classified into the > >>> following 3 statuses: > >>> 1. &qu
Re: [OE-core] [PATCH v2] cve-check: Classify patched CVEs into 3 statuses
Hello Andrej,
This patch is splitting the Patched state, not the ignore one. This is not
incorrect CPE or anything else.
Currently Patched means one of two situations: either this issue has never
affected the code base (example: we have version 1.0, issue was introduced
in 2.0 and fixed in 2.1), or the issue has been fixed.
Yes, another reason to say ignore, not affected is a manual analysis
showing a thing like: the issue affects only windows.
Regards,
Marta
On Wed, 25 Oct 2023, 12:18 Andrej Valek, wrote:
> Hi Marta,
>
> That's fine, as I said we designed the "ignore" with status
> "cpe-incorrect" or "ignored" exactly for those purposes. Extending the
> option with "not affected" doesn't make any sense.
>
> You have to set the status to "why is not affected" = "ignored". Which
> completely covers the requested case.
>
> Regards,
> Andrej
>
> On 25.10.2023 11:33, Marta Rybczynska wrote:
> > Hi Andrej,
> > This is more complex. "Not affected" is also an issue that isn't present
> in the
> > code - like when we have a version that has never had the vulnerability.
> > Those are also currently 'Patched' in cve-check.
> >
> > This work is in sync with what VEX is doing, is it the use-case
> > Matsanaga-Shinji?
> >
> > Regards,
> > Marta
> >
> > On Wed, Oct 25, 2023 at 8:44 AM Andrej Valek
> wrote:
> >> Hi all,
> >>
> >> Do we really need a new "not_affected" state? I guess the ignore state
> >> is exactly designed for those purposes.
> >>
> >> Regards,
> >> Andrej
> >>
> >> On 25.10.2023 07:13, Matsunaga-Shinji wrote:
> >>> CVEs that are currently considered "Patched" are classified into the
> following 3 statuses:
> >>> 1. "Patched" - means that a patch file that fixed the
> vulnerability has been applied
> >>> 2. "Not affected" - means that the package version (PV) is not
> affected by the vulnerability
> >>> 3. "Undecidable" - means that versions cannot be compared to
> determine if they are affected by the vulnerability
> >>>
> >>> Signed-off-by: Shinji Matsunaga
> >>> Signed-off-by: Shunsuke Tokumoto
> >>> ---
> >>>
> >>> Changes for v2:
> >>> - Fix the status "Out of range" to "Not affected"
> >>>
> >>>meta/classes/cve-check.bbclass | 55
> +++---
> >>>1 file changed, 38 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/meta/classes/cve-check.bbclass
> b/meta/classes/cve-check.bbclass
> >>> index b55f4299da..502db324df 100644
> >>> --- a/meta/classes/cve-check.bbclass
> >>> +++ b/meta/classes/cve-check.bbclass
> >>> @@ -185,10 +185,10 @@ python do_cve_check () {
> >>>patched_cves = get_patched_cves(d)
> >>>except FileNotFoundError:
> >>>bb.fatal("Failure in searching patches")
> >>> -ignored, patched, unpatched, status = check_cves(d,
> patched_cves)
> >>> -if patched or unpatched or
> (d.getVar("CVE_CHECK_COVERAGE") == "1" and status):
> >>> -cve_data = get_cve_info(d, patched + unpatched +
> ignored)
> >>> -cve_write_data(d, patched, unpatched, ignored,
> cve_data, status)
> >>> +ignored, patched, unpatched, not_affected, undecidable,
> status = check_cves(d, patched_cves)
> >>> +if patched or unpatched or not_affected or undecidable or
> (d.getVar("CVE_CHECK_COVERAGE") == "1" and status):
> >>> +cve_data = get_cve_info(d, patched + unpatched +
> ignored + not_affected + undecidable)
> >>> +cve_write_data(d, patched, unpatched, ignored,
> not_affected, undecidable, cve_data, status)
> >>>else:
> >>>bb.note("No CVE database found, skipping CVE check")
> >>>
> >>> @@ -308,13 +308,13 @@ def check_cves(d, patched_cves):
> >>>products = d.getVar("CVE_PRODUCT").split()
> >>># If this has been unset then we're not scanning for CVEs here
> (for example, image recipes)
> >>>if not products:
> >>> -return ([], [], [], [])
> >>> +return ([], [], [], [], [], [])
> >>>pv = d.getV
Re: [OE-core] [PATCH v2] cve-check: Classify patched CVEs into 3 statuses
Hi Andrej,
This is more complex. "Not affected" is also an issue that isn't present in the
code - like when we have a version that has never had the vulnerability.
Those are also currently 'Patched' in cve-check.
This work is in sync with what VEX is doing, is it the use-case
Matsanaga-Shinji?
Regards,
Marta
On Wed, Oct 25, 2023 at 8:44 AM Andrej Valek wrote:
>
> Hi all,
>
> Do we really need a new "not_affected" state? I guess the ignore state
> is exactly designed for those purposes.
>
> Regards,
> Andrej
>
> On 25.10.2023 07:13, Matsunaga-Shinji wrote:
> > CVEs that are currently considered "Patched" are classified into the
> > following 3 statuses:
> > 1. "Patched" - means that a patch file that fixed the vulnerability
> > has been applied
> > 2. "Not affected" - means that the package version (PV) is not affected by
> > the vulnerability
> > 3. "Undecidable" - means that versions cannot be compared to determine if
> > they are affected by the vulnerability
> >
> > Signed-off-by: Shinji Matsunaga
> > Signed-off-by: Shunsuke Tokumoto
> > ---
> >
> > Changes for v2:
> > - Fix the status "Out of range" to "Not affected"
> >
> > meta/classes/cve-check.bbclass | 55 +++---
> > 1 file changed, 38 insertions(+), 17 deletions(-)
> >
> > diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
> > index b55f4299da..502db324df 100644
> > --- a/meta/classes/cve-check.bbclass
> > +++ b/meta/classes/cve-check.bbclass
> > @@ -185,10 +185,10 @@ python do_cve_check () {
> > patched_cves = get_patched_cves(d)
> > except FileNotFoundError:
> > bb.fatal("Failure in searching patches")
> > -ignored, patched, unpatched, status = check_cves(d,
> > patched_cves)
> > -if patched or unpatched or (d.getVar("CVE_CHECK_COVERAGE") ==
> > "1" and status):
> > -cve_data = get_cve_info(d, patched + unpatched + ignored)
> > -cve_write_data(d, patched, unpatched, ignored, cve_data,
> > status)
> > +ignored, patched, unpatched, not_affected, undecidable, status
> > = check_cves(d, patched_cves)
> > +if patched or unpatched or not_affected or undecidable or
> > (d.getVar("CVE_CHECK_COVERAGE") == "1" and status):
> > +cve_data = get_cve_info(d, patched + unpatched + ignored +
> > not_affected + undecidable)
> > +cve_write_data(d, patched, unpatched, ignored,
> > not_affected, undecidable, cve_data, status)
> > else:
> > bb.note("No CVE database found, skipping CVE check")
> >
> > @@ -308,13 +308,13 @@ def check_cves(d, patched_cves):
> > products = d.getVar("CVE_PRODUCT").split()
> > # If this has been unset then we're not scanning for CVEs here (for
> > example, image recipes)
> > if not products:
> > -return ([], [], [], [])
> > +return ([], [], [], [], [], [])
> > pv = d.getVar("CVE_VERSION").split("+git")[0]
> >
> > # If the recipe has been skipped/ignored we return empty lists
> > if pn in d.getVar("CVE_CHECK_SKIP_RECIPE").split():
> > bb.note("Recipe has been skipped by cve-check")
> > -return ([], [], [], [])
> > +return ([], [], [], [], [], [])
> >
> > # Convert CVE_STATUS into ignored CVEs and check validity
> > cve_ignore = []
> > @@ -328,6 +328,8 @@ def check_cves(d, patched_cves):
> > conn = sqlite3.connect(db_file, uri=True)
> >
> > # For each of the known product names (e.g. curl has CPEs using curl
> > and libcurl)...
> > +cves_not_affected = []
> > +cves_undecidable = []
> > for product in products:
> > cves_in_product = False
> > if ":" in product:
> > @@ -355,6 +357,7 @@ def check_cves(d, patched_cves):
> >
> > vulnerable = False
> > ignored = False
> > +undecidable = False
> >
> > product_cursor = conn.execute("SELECT * FROM PRODUCTS WHERE
> > ID IS ? AND PRODUCT IS ? AND VENDOR LIKE ?", (cve, product, vendor))
> > for row in product_cursor:
> > @@ -376,7 +379,7 @@ def check_cves(d, patched_cves):
> > except:
> > bb.warn("%s: Failed to compare %s %s %s for
> > %s" %
> > (product, pv, operator_start,
> > version_start, cve))
> > -vulnerable_start = False
> > +undecidable = True
> > else:
> > vulnerable_start = False
> >
> > @@ -387,10 +390,15 @@ def check_cves(d, patched_cves):
> > except:
> > bb.warn("%s: Failed to compare %s %s %s for
> > %s" %
> > (product, pv, operator_end,
> > version_end, cve))
> > -vulnerable_end = False
> > +
Re: [OE-core] CVE work synchronization proposal
On Fri, Oct 20, 2023 at 4:18 PM Michael Opdenacker wrote: > > Hi Marta > > On 20.10.23 at 10:36, Marta Rybczynska wrote: > > Hello everyone, > > We have a constant flow of work on pending CVEs. During my discussion > > with multiple people, there is a common need for synchronization of > > this work to avoid duplication or forgotten fixes. > > > > We have a decision on the tooling to make: do we want to create a > > Bugzilla entry for each new open CVE? An alternative is to use a wiki > > page (this has been prototyped by Ross) with heavy scripting to > > automate the tedious part. > > > > Today I propose you to use a special wiki page and the following procedure: > > > > On the wiki page, always add all additional information after a ; sign > > to allow scripting. The first part of each line (until ";" ) will be > > auto-generated. The second part contains information about the issue, > > like who is investigating or what the situation is. > > > > There is a separate list for each branch, as we realize that people > > concentrate on various branches. > > > > Workflow: > > > > * Mark name of a person preparing a patch for each branch > > * If you have additional information (like a link to a patch), add it > > to the record > > * If a patch is posted to the mailing list, post a link to it (this > > will be automated) > > * When a patch reaches the "next" branch, mark it too (this will be > > automated too) > > * When the patch reaches the final branch, the line of the CVE is > > automatically removed (this is already automated) > > * The list is (re)generated every day > > > > > > Please have a look at the procedure proposal and how the tracking > > might look like: > > > > https://wiki.yoctoproject.org/wiki/Synchronization_CVEs > > > This looks very useful. Thanks! > If I understand correctly, the fact that the beginning of each line is > generated automatically is a way to make sure nobody with Wiki write > rights can hide a vulnerability by removing it from the list, right? > Hello Michael, The auto-generation has multiple benefits: * no removing by error or any other reason, while the vulnerability is still there -> it will be re-added the next day * less time spent to review the list Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189669): https://lists.openembedded.org/g/openembedded-core/message/189669 Mute This Topic: https://lists.openembedded.org/mt/102077364/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] CVE work synchronization proposal
Hello everyone, We have a constant flow of work on pending CVEs. During my discussion with multiple people, there is a common need for synchronization of this work to avoid duplication or forgotten fixes. We have a decision on the tooling to make: do we want to create a Bugzilla entry for each new open CVE? An alternative is to use a wiki page (this has been prototyped by Ross) with heavy scripting to automate the tedious part. Today I propose you to use a special wiki page and the following procedure: On the wiki page, always add all additional information after a ; sign to allow scripting. The first part of each line (until ";" ) will be auto-generated. The second part contains information about the issue, like who is investigating or what the situation is. There is a separate list for each branch, as we realize that people concentrate on various branches. Workflow: * Mark name of a person preparing a patch for each branch * If you have additional information (like a link to a patch), add it to the record * If a patch is posted to the mailing list, post a link to it (this will be automated) * When a patch reaches the "next" branch, mark it too (this will be automated too) * When the patch reaches the final branch, the line of the CVE is automatically removed (this is already automated) * The list is (re)generated every day Please have a look at the procedure proposal and how the tracking might look like: https://wiki.yoctoproject.org/wiki/Synchronization_CVEs Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189510): https://lists.openembedded.org/g/openembedded-core/message/189510 Mute This Topic: https://lists.openembedded.org/mt/102077364/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] cve-check.bbclass: support embedded SW components with different version number
On Mon, Oct 16, 2023 at 9:01 AM Mikko Rapeli wrote: > > Many recipes embed other SW components. The name and version of the > embedded SW component differs from the main recipe. To detect CVEs in the > embedded SW component, it needs to be added to CVE_PRODUCT list using > name of the SW product in CVE database or with "vendor:product" syntax. > Then the version of the embedded SW component can be set using > CVE_VERSION_product variable. > > For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component. > Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database > uses product name "mbed_tls": > > CVE_PRODUCT += "mbed_tls" > > and set the version of mbed_tls: > > CVE_VERSION_mbed_tls = "2.28.4" > > (Real patches for both are a bit more complex due to conditional build > enabling mbed_tls support and due to mbed_tls version being set in an > .inc file.) > I like the support for embedded software. In this approach, I'm wondering how it would work for packages like curl that have multiple CPEs. Would we need to duplicate the list of CPEs? There are layers/recipes where we have a very long list of embedded components, meta-zephyr is probably the best example. Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189434): https://lists.openembedded.org/g/openembedded-core/message/189434 Mute This Topic: https://lists.openembedded.org/mt/101991269/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[PATCH v2][OE-core] SECURITY.md: add file
Add a SECURITY.md file with hints for security researchers and other parties who might report potential security vulnerabilities. Signed-off-by: Marta Rybczynska --- SECURITY.md | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00..1b63da4f69 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,22 @@ +How to Report a Potential Vulnerability? + + +If you would like to report a public issue (for example, one with a released +CVE number), please report it using the +[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security Bugzilla] + +If you are dealing with a not-yet released or urgent issue, please send a +message to security AT yoctoproject DOT org, including as many details as +possible: the layer or software module affected, the recipe and its version, +and any example code, if available. + +Branches maintained with security fixes +--- + +See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS] +for detailed info regarding the policies and maintenance of Stable branches. + +The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all +releases of the Yocto Project. Versions in grey are no longer actively maintained with +security patches, but well-tested patches may still be accepted for them for +significant issues. -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189367): https://lists.openembedded.org/g/openembedded-core/message/189367 Mute This Topic: https://lists.openembedded.org/mt/102034116/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] Add SECURITY.md
On Tue, Oct 17, 2023 at 11:50 PM Richard Purdie wrote: > > On Tue, 2023-10-17 at 17:25 +0200, Marta Rybczynska wrote: > > Add a SECURITY.md filr with hints for security researchers and other > > parties who might report potential security vulnerabilities. > > > > Signed-off-by: Marta Rybczynska > > --- > > SECURITY.md | 17 + > > 1 file changed, 17 insertions(+) > > create mode 100644 SECURITY.md > > > > diff --git a/SECURITY.md b/SECURITY.md > > new file mode 100644 > > index 00..900da76e59 > > --- /dev/null > > +++ b/SECURITY.md > > @@ -0,0 +1,17 @@ > > +How to Report a Vulnerability? > > +== > > + > > +Please send a message to security AT yoctoproject DOT org, including as > > many details > > +as possible: the layer or software module affected, the recipe and its > > version, > > +and any example code, if available. > > Rather than send everyone to the security address, can we suggest > bugzilla as the first port of call for anything public knowledge and > less urgent and to only to use the security address for non-public or > urgent issues? > > We do have the ability to mark bugs as security and private and then > triage unlocks them too. > Absolutely. I will be sending a v2 to OE-core only. When we agree on this one, I will send it also to other layers. As they might come in different combinations, a SECURITY.md for each layer (like README) gives us best visibility. Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189366): https://lists.openembedded.org/g/openembedded-core/message/189366 Mute This Topic: https://lists.openembedded.org/mt/102019988/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] Add SECURITY.md
Add a SECURITY.md filr with hints for security researchers and other parties who might report potential security vulnerabilities. Signed-off-by: Marta Rybczynska --- SECURITY.md | 17 + 1 file changed, 17 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00..900da76e59 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,17 @@ +How to Report a Vulnerability? +== + +Please send a message to security AT yoctoproject DOT org, including as many details +as possible: the layer or software module affected, the recipe and its version, +and any example code, if available. + +Branches maintained with security fixes +--- + +See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS] +for detailed info regarding the policies and maintenance of Stable branch. + +The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all +releases of the Yocto Project. Versions in grey are no longer actively maintained with +security patches, but well-tested patches may still be accepted for them for +significant issues. -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189341): https://lists.openembedded.org/g/openembedded-core/message/189341 Mute This Topic: https://lists.openembedded.org/mt/102019988/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] cve-check: Classify patched CVEs into 3 statuses
On Thu, 21 Sept 2023, 11:03 Matsunaga-Shinji, wrote: > CVEs that are currently considered "Patched" are classified into the > following 3 statuses: > 1. "Patched" - means that a patch file that fixed the vulnerability > has been applied > 2. "Out of range" - means that the package version (PV) is not subject to > the vulnerability > 3. "Undecidable" - means that versions cannot be compared to determine if > they are affected by the vulnerability Hello, Thank you for your patch. I'm wondering what you use case is. What do you do with that data? Currently in YP we aim to do as much as automatic classification as we can. We only adjust the classification manually when it is clearly wrong. Now, in this piece of code I don't see setting up 'out-of-range', while it is possible to separate the not affected case and the case when we apply a patch. I do not understand the 'undecideable' classification. Could you give an exemple of a situation when it makes sense to use it? On the naming side, I'd prefer 'Not Affected' for out-of-range, because that term is often used in error conditions. In this case there is no error at all. Kind regards, Marta > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#188666): https://lists.openembedded.org/g/openembedded-core/message/188666 Mute This Topic: https://lists.openembedded.org/mt/101496298/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] An insight into the kind of help we need/maintainer overload
On Mon, Oct 2, 2023 at 12:40 PM Richard Purdie wrote: > > It isn't any secret that I'm overloaded and struggle to keep up with > the demands of the project. People often ask me "how do you need > help?". Today, we have a fairly good example of the kind of problem I > struggle with. So it is documented, I'll describe my side of the > challenge. > > We're supposed to be building the final release candidates for 4.3 > today. We've also just found out that the 6.4 kernel is EOL much sooner > than we guessed. The choice is ship with a known working but > unsupportable kernel (no security updates), or try and switch to 6.5. > > Over the weekend (when I should really be doing anything but work), I > tested the preliminary 6.5 patches Bruce was kind enough to prepare on > the autobuilder. > > Just getting to this point is a ton of work for Bruce which goes on > quietly relatively unrecognised. The -dev kernel has been used to try > and prepare for the future kernel upgrades and without that we wouldn't > be at this point already. I'm going to focus on the challenges I have > but I want to recognise others have already faced issues just to get to > this point. > > On the autobuilder we found that: > > a) cryptodev breaks > b) LTP ARM testing OOMs and crashes badly > c) ARM ptests are hitting jitterentropy issues intermittently (~ a >third fail) > d) x86 qemu image tests are failing say 5% of the time which means 3-4 >of 5 oe-selftest fail plus some other random failures > e) strace ptests are failing > f) meta-virtualization breaks > > Bruce can't be expected to test or fix everything. Some of these issues > have all the hallmarks of being really painful to fix. > > a) is trivial, there is a patch in master-next. Being selfish, f) isn't > my problem. It is Bruce's though and will distract him from other > kernel things. e) is probably deterministic and can either be fixed or > disabled. > > This leaves b/c/d as the scary problems. > > c) has already been reported on the kernel lists but nobody responded. > Not a good sign. I've looked to see if we can disable it but we'd have > to disable the bluetooth stack to do so. > > The memory issues in b) if reported upstream will be pushed back with > "why not add more memory?" or "what is using the memory? Please debug > it and tell us how to fix it". Whilst I appreciate this is how the > world works, it is frustrating as we're effectively on our own until we > present it to upstream on a plate. > > The issues in d) are the scariest of the lot. A rare ish non- > determinstic failure we can't talk to anyone about until we narrow the > issue down. If I try and share with others, they'll ask how to > reproduce and I simply don't know at this point. Engineers don't like > to touch problems without a reproduction mechanism. > > Even just asking others about this has people asking "where is the bug > report I can look at?". Given most of this happened over the weekend, I > haven't written bug reports and that in itself is a lot of work even > collecting up the information from the failed builds. > > So what do I do? > > I have no engineers I can "assign" to this. Our kernel maintainer will > help but only has finite time they can spend on upstream work and the > shear number of issues means they are unlikely to get all the issues > resolved alone. > > Can we afford to fix this in several weeks time? No, we can't as we > need to build 4.3 now so there is time pressure. > > I can ask for help from others and I will/have but most people can't > drop everything and dive into this. This leaves my own time as about > the only thing I can directly control/contribute. > > If these things happen very occasionally, they can be managed. It does > feel like other upstreams are getting stretched more thinly,, quality > is getting worse and they're pushing more bug resolution to their > consumers. Yocto Project users are also pulling their engineers to > internal/product focused work and I'm left in the middle with > increasing work and fewer resources. > > I will likely take 48 hours to work out what we can do. If we can't > find a line of sight on resolving the issues, the outcode after that > time really has to be one of "ship 6.4, who cares about security" or > "delay the release X (4?) weeks and hope for the best". > > If anyone has any idea of how to solve these process/resource issues, > or what I should be going differently, let me know. I am really tempted > just to stick with 6.4 as I really don't need these kind of problems. > Hello Richard, I'm sorry hearing that. However, I find your analysis factual and complete. I'm wondering about one thing (maybe missing some background): what about the option of using 6.1 by default and disabling both 6.4 and 6.5 ? Shipping EOLed 6.4 would have an seriously bad impact on the project image, in my opinion. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#188641):
Re: [OE-core] [Openembedded-architecture] [yocto] Security processes: YP needs
On Wed, 27 Sept 2023, 12:05 Reyna, David, wrote: > Hi Marta! > > > What about 11am Pacific on tomorrow (28 Sept or Oct 3)? > > Let us aim for October 3 so that I can prepare a full demo.. > > > I think that you have meant 10am to 2PM, otherwise 1am Pacific would > work very well for me too > > I actually did mean 2:00 am Pacific. I do work with our India team, so I > am often up late to sync with them.. > > > As discussed yesterday in the call, there are some other people who seem > interested. > > What time zone are you in? > I believe Ross is in England (UTC) > I know that Randy is in Ottawa. > > If anyone else wants to join, that would be great!. They should ping us > and I can send the Zoom link. I do not want to send that link blindly to > the full mail list. > I'm in CEST (Central European zone). If we aim for the 3rd then let's stay for late afternoon for me. I let Ross, Randy and everyone else interested to express their preferences. > > I'm going to add the missing file for the test next week, the tool needs > a script to download 2023 data. > > That file is part of my code update, so you can get that for free. > Thanks! David > > -Original Message- > From: Marta Rybczynska > Sent: Wednesday, September 27, 2023 12:18 AM > To: Reyna, David > Cc: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-core@lists.openembedded.org>; > openembedded-architect...@lists.openembedded.org; > yo...@lists.yoctoproject.org; MacLeod, Randy ; > Richard Purdie ; Steve Sakoman < > st...@sakoman.com>; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP > needs > > Hi David, > Thank you very much for the description and the offer to get a demo. > As discussed yesterday in the call, there are some other people who > seem interested. > > > PROPOSAL 1: If the full triage is too much to bite off to start with, > perhaps using it to track and coordinate work will bring immediate benefit. > > This is the reason I want to test how much time it takes. > > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. > I am available pretty much anytime between 10:00 am Pacific to 2:00 am > Pacific. > > That would be nice. What about 11am Pacific on tomorrow (28 Sept or > Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific > would work very well for me too :P > > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my > current implementation level from Wind River (with the Wind River specific > modules left out of course :-) > > That would be great. I'm going to add the missing file for the test > next week, the tool needs a script to download 2023 data. > > Kind regards, > Marta > > On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via > lists.openembedded.org > wrote: > > > > Hi Marta, > > > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > > > There are many ways to use the SRTool. > > (a) The original design was to perform 100% triage of incoming CVEs. > This was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > > (b) The main limitation with the SRTool for Yocto Project was the > lack of integration with Bugzilla (Ross ran out of time) > > * This is the crucial other half of the workflow > > * There is the automatic creation of appropriate defect records for > investigation > > * There is also the automatic tracking of the overall CVE status, > both CVEs in progress and the CVEs completed > > * Wind River has an extension for full integration with Jira, and > that saves weeks of work for the CVE management > > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate > of domains > > (d) The SRTool has a user model > > * Together with Bugzilla, it is easy to track single people and > even multiple people working on CVEs > > (e) The SRTool also has the built-on ability to look up the CVE status > from other distributions (Red Hat, Debian, ...) so that one can get a peek > of existing triages and resolutions > > (f) The SRTool is build like Toaster on top of Django, so development > and debugging skills for Toaster immediate apply > > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support
Re: [OE-core] [Openembedded-architecture] [yocto] Security processes: YP needs
Hi David, Thank you very much for the description and the offer to get a demo. As discussed yesterday in the call, there are some other people who seem interested. > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. This is the reason I want to test how much time it takes. > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. That would be nice. What about 11am Pacific on tomorrow (28 Sept or Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific would work very well for me too :P > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) That would be great. I'm going to add the missing file for the test next week, the tool needs a script to download 2023 data. Kind regards, Marta On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via lists.openembedded.org wrote: > > Hi Marta, > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > There are many ways to use the SRTool. > (a) The original design was to perform 100% triage of incoming CVEs. This > was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > (b) The main limitation with the SRTool for Yocto Project was the lack of > integration with Bugzilla (Ross ran out of time) > * This is the crucial other half of the workflow > * There is the automatic creation of appropriate defect records for > investigation > * There is also the automatic tracking of the overall CVE status, both > CVEs in progress and the CVEs completed > * Wind River has an extension for full integration with Jira, and that > saves weeks of work for the CVE management > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate of > domains > (d) The SRTool has a user model > * Together with Bugzilla, it is easy to track single people and even > multiple people working on CVEs > (e) The SRTool also has the built-on ability to look up the CVE status from > other distributions (Red Hat, Debian, ...) so that one can get a peek of > existing triages and resolutions > (f) The SRTool is build like Toaster on top of Django, so development and > debugging skills for Toaster immediate apply > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support for example CVE Scanner integration > (h) The SRTool also has report generation (in text, CSV, and Excel) in > addition to email notification support. > (i) There is also a "private" model for CVEs under embargo, with strict > access control lists. > > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) > > David > > BTW, I also support an extension to the SRTool that manages CVE scanning of > build images, with hooks to a number existing CVE scanners (e.g. Trivy) in > addition to other vulnerability metrics. This is probably out of scope to YP > at this time, but it is perhaps something to grow in to. > > -Original Message- > From: yo...@lists.yoctoproject.org On Behalf > Of Marta Rybczynska via lists.yoctoproject.org > Sent: Wednesday, September 13, 2023 4:52 AM > To: yocto-secur...@lists.yoctoproject.org; OE-core > ; > openembedded-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org > Cc: Richard Purdie ; Steve Sakoman > ; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: [yocto] Security processes: YP needs > > Hello, > I've been working recently on collecting what works and what doesn't > in YP security processes. The goal is to go forward and define an > actionable strategy! > > Today, I'd like to share with you the summary of what I have heard as > needs from several people (those in Cc:). > > I want the
Re: [OE-core] [PATCH 06/17] python3-click: Copy recipe from meta-python
Sure Khem,
We wanted to make sure there are no major objections to this patchset and
immediately follow with removals in meta-openembedded.
Cheers,
Marta
On Fri, 22 Sept 2023, 17:24 Khem Raj, wrote:
> On 9/22/23 7:46 AM, Samantha Jalabert wrote:
> > From: Samantha Jalabert
> >
> > commit: 1a14a28f132a10e9db7b3e5bb2b5361c4679946e
> >
> > Signed-off-by: Marta Rybczynska
>
> Please send a removal patch for meta-python as well. So we can keep
> passing the yp compat checks for meta-openembedded on AB and coordinate
> the change between meta-python and oe-core
>
> > ---
> > .../python/python3-click/run-ptest| 3 ++
> > .../python/python3-click_8.1.7.bb | 39 +++
> > 2 files changed, 42 insertions(+)
> > create mode 100644 meta/recipes-devtools/python/python3-click/run-ptest
> > create mode 100644 meta/recipes-devtools/python/python3-click_8.1.7.bb
> >
> > diff --git a/meta/recipes-devtools/python/python3-click/run-ptest
> b/meta/recipes-devtools/python/python3-click/run-ptest
> > new file mode 100644
> > index 00..b63c4de0d9
> > --- /dev/null
> > +++ b/meta/recipes-devtools/python/python3-click/run-ptest
> > @@ -0,0 +1,3 @@
> > +#!/bin/sh
> > +
> > +pytest -o log_cli=true -o log_cli_level=INFO | sed -e 's/\[...%\]//g'|
> sed -e 's/PASSED/PASS/g'| sed -e 's/FAILED/FAIL/g'|sed -e
> 's/SKIPPED/SKIP/g'| awk '{if ($NF=="PASS" || $NF=="FAIL" || $NF=="SKIP" ||
> $NF=="XFAIL" || $NF=="XPASS"){printf "%s: %s\n", $NF, $0}else{print}}'| awk
> '{if ($NF=="PASS" || $NF=="FAIL" || $NF=="SKIP" || $NF=="XFAIL" ||
> $NF=="XPASS") {$NF="";print $0}else{print}}'
> > diff --git a/meta/recipes-devtools/python/python3-click_8.1.7.bb
> b/meta/recipes-devtools/python/python3-click_8.1.7.bb
> > new file mode 100644
> > index 00..a4ec6cd1ef
> > --- /dev/null
> > +++ b/meta/recipes-devtools/python/python3-click_8.1.7.bb
> > @@ -0,0 +1,39 @@
> > +SUMMARY = "A simple wrapper around optparse for powerful command line
> utilities."
> > +DESCRIPTION = "\
> > +Click is a Python package for creating beautiful command line
> interfaces \
> > +in a composable way with as little code as necessary. It's the "Command
> \
> > +Line Interface Creation Kit". It's highly configurable but comes with \
> > +sensible defaults out of the box."
> > +HOMEPAGE = "http://click.pocoo.org/;
> > +LICENSE = "BSD-3-Clause"
> > +LIC_FILES_CHKSUM =
> "file://LICENSE.rst;md5=1fa98232fd645608937a0fdc82e999b8"
> > +
> > +SRC_URI[sha256sum] =
> "ca9853ad459e787e2192211578cc907e7594e294c7ccc834310722b41b9ca6de"
> > +
> > +inherit pypi setuptools3 ptest
> > +
> > +SRC_URI += "file://run-ptest"
> > +
> > +RDEPENDS:${PN}-ptest += " \
> > + ${PYTHON_PN}-pytest \
> > + ${PYTHON_PN}-terminal \
> > + ${PYTHON_PN}-unixadmin \
> > +"
> > +
> > +do_install_ptest() {
> > +install -d ${D}${PTEST_PATH}/tests
> > +cp -rf ${S}/tests/* ${D}${PTEST_PATH}/tests/
> > +cp -rf ${S}/setup.cfg ${D}${PTEST_PATH}/
> > +cp -rf ${S}/docs ${D}${PTEST_PATH}/
> > +}
> > +
> > +UPSTREAM_CHECK_REGEX = "click/(?P\d+(\.\d+)+)/"
> > +
> > +CLEANBROKEN = "1"
> > +
> > +RDEPENDS:${PN} += "\
> > +${PYTHON_PN}-io \
> > +${PYTHON_PN}-threading \
> > +"
> > +
> > +BBCLASSEXTEND = "native nativesdk"
> >
> >
> >
> >
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188131):
https://lists.openembedded.org/g/openembedded-core/message/188131
Mute This Topic: https://lists.openembedded.org/mt/101522496/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] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle wrote: > >> * Visibility of the security work of the YP > >> > >> There is much work on security in the YP, but it lacks visibility. > > > > Is there a common nexus for this work? eg. do most of the folks who are > > doing security work tend to congregate on the security sublist? > > Security means different things to different people. I.e. > > 1) Secure design > - Is the system designed to have security services, if so are the defaults > setup to both be appropriate and also functional? > > 2) Additional security software > - i.e. meta-security, what additional software can be available to enhance > security design/implementation of the system > > 3) Security (bug) response > - This is where I see a lack of common nexus for work. We don't have a > good > place to discuss CVE specific information. Now the question really is, should > we have a separate space. CVEs are just bugs. Bugs are usually worked on via > the main mailing list. So that argument says no, we shouldn't have a special > list. BUT the perception is CVEs are "special", so maybe a list specifically > to > discuss the ramifications of a CVE, fix/mitigation strategy or similar would > make sense -- keeping actual bug fixes to the main mailing list? > It might e interesting to have opinion on people who are submitting CVE fixes... Would keeping that discussion in a separate place be helpful? > >> > >> * SRTool > >> > >> We might decide to use it again. It allows one to do much but requires > >> constant commitment. > > > > I think I passed over the wiki pages and presentations for SRTool once, > > a while ago. But I didn't pay much attention at the time because it > > wasn't clear *what it did*. > > > > After reviewing it again, I think it might be the kind of tooling I've > > been searching for to help my team coordinate our CVE response work. > > I'll test it out and see if it is something I can use/contribute towards. > > SR Tool requires constant feeding and maintenance from staff, at a minimum to > do > initial triage work. This means we need a small group of individuals who can > take the new items (and changes to existing) and comment on a regular (daily) > basis. This is the part we've not been terribly successful in the past. > People > are great at delivering patches, but trying to do the proactive (before > cve-checker) evaluation of CVEs is an activity that often feels like busy > work, > so it's easy to get behind on and never catch up. > > I would love to see the project use SR Tool to manage CVE information, > (bugzilla > is where the bugs need to be managed and processed), as well as cve-checker to > be able to continue to feed information or what we believe the current state > of > things are. This combination would give us per-emptive notification of new > items (SR-Tool), and late validation of items (cve-checker) on the perceived > state of things. SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for 4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver going to update the fork? David (adding in copy), do you have any information? Otherwise we would need to maintain our version, and update to the code to take into account how the world have changed. For example, with the CVE v5 JSON, using the CVE database directly for the feed of new CVE list makes more sense than using NVD, for example. For the reason of performance and delay. When SRTool was developed, that data wasn't available. Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187660): https://lists.openembedded.org/g/openembedded-core/message/187660 Mute This Topic: https://lists.openembedded.org/mt/101340097/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] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart wrote: > > Thanks for driving this Marta. Internally and externally, it feels like > we're just on the cusp of everyone *suddenly caring* about our security > response strategy. So it's good to see that we're making moves in that > direction. > Thank you Alex! > > More responses inline. > > On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: > > * CVEs: Visibility if YP is vulnerable or not > > > > People want to be able to check/look up a specific CVE; it might be a > > CVE unrelated to YP > > (eg. package not included, Windows issue). The cve-checker result is a > > part of the solution, but people also want to know which CVEs do not > > apply. > > I'm not sure I understand this usecase. Is there a reason those people > can't/won't just lookup the CVE on the NIST site? > Mark's answer is clarifying that. I'll add that this is a requirement I have heard from multiple sources. People might look up CVE/NIST, but that takes time if you are required to look up all CVEs. If we have common data, we avoid duplicate work. > > * CVEs: synchronization of the work on fixes > > > > Currently, there is no synchronization; multiple parties might be > > working on the same fix while nobody is working on another. There > > might be duplication of work. > > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > Has there been any discussion of adopting the OpenVEX document standard > that the Chainguard guys are putting together? [1] It seems like the VEX > use-cases align well with our needs around tracking and coordinating CVE > response between YP member and individual developers. > We might decide to use it. However, openVEX a way to output the data we have/will have (the conclusion), not a way to sync up the work. > > > * Triaging of security issues > > > > Related to CVE fixes and includes issues reported directly to the YP. > > Some issues are more likely to be serious for embedded products > > (attack by network), so not all has the same priority. > > I'll note here that some of us are sinners and do actually support > network-attached (and internet-attached) embedded devices. :) > > But the greater point of OS vendors being able to triage and assign > vendor-specific severities to incoming issues is absolutely important to > my use-cases. > This is an important point. YP is generic and YP assesment of severity might be different than the one from a vendor. It means that our process should be flexible enough that a vendor can take the data and assign their own severity. > > > > * Visibility of the security work of the YP > > > > There is much work on security in the YP, but it lacks visibility. > > Is there a common nexus for this work? eg. do most of the folks who are > doing security work tend to congregate on the security sublist? I'd like to know :) This thread is a big cross-post (and sorry for that, but I need to reach the whole audience), for further discussions I'd like to invite all to a dedicate list. > > > * Additional tooling > > > > We could add additional tooling: a template on how to add cve-check to > > the CI (possibly > > a different one than the autobuilder), analyze the result, and extend > > our tooling to their layers... > > It is also related to the "Architecture" topic below. > > Can you expand on what you mean here? Is this usecase about extending > the existing tooling into the generic CI processes that YP members are > using, or about expanding the tooling in the YP's indigenous CI? This is a requirement assembling multiple ones. Many people mentioned that additional tooling would be needed and/or helpful. A CI template is an example here. I'm interested in your list of tooling that would be important or useful to have. Preferably related to processes that are currently done in-house and that we can make more generic and share the work. > > > * Presence on pre-notification lists and receiving information before > > the vulnerability gets public > > > > YP currently depends on public data. Principal distributions receive > > the information before > > a vulnerability becomes public. It requires (in short) private > > reporting, a security team, and a track > > of excellent security record. > > > > * Becoming a CNA (be able to assign CVEs) > > > > Needed if we want to assign CVEs to the software of the YP, like > > autobuilder, Toaster etc. > > I'm also interested in this, as the maintainer of our opkg fork. So far, > I haven't had to respond to a CVE against the project, but that won't > last forever. CVEs again
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli wrote: > > Hi, > > On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > > Hello, > > I've been working recently on collecting what works and what doesn't > > in YP security processes. The goal is to go forward and define an > > actionable strategy! > > > > Today, I'd like to share with you the summary of what I have heard as > > needs from several people (those in Cc:). > > > > I want the community to comment and tell us what you find important > > and what you'd like to see added or changed from this list. > > Since most users take poky reference distro and combine it with a number > of open source and closed source BSP and other meta layers and build > systems to produce SW for products, they also need documentation and tooling > so that they can replicate the Yocto Project security processes and use the > available tools. Do you also mean that we should make sure Poky follows security best practices? Noted the point on documenting the way process works/will work so other teams can extend it to their layer. > > I think most of the documentation around the tools and processes is in place > already. > Having maintained and shipped from a non-maintained poky branch, I can just > say > thank you to all who participated in the upstream work to get security > vulnerability > detection and fixing possible! > Out of curiosity, what have you backported? cve-check? LTS work? > That being said, extending the CVE scanning and status tracking work to > include more > open source layers would be nice both for the maintainers and for the users > of those > layers. Using some random old branch of meta-foo may not be so safe. Maybe add > this data to layer-index? > We have Yocto Project Compatible already. Do we need something else? Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187653): https://lists.openembedded.org/g/openembedded-core/message/187653 Mute This Topic: https://lists.openembedded.org/mt/101335537/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Security processes: YP needs
Hello, I've been working recently on collecting what works and what doesn't in YP security processes. The goal is to go forward and define an actionable strategy! Today, I'd like to share with you the summary of what I have heard as needs from several people (those in Cc:). I want the community to comment and tell us what you find important and what you'd like to see added or changed from this list. * CVEs: Visibility if YP is vulnerable or not People want to be able to check/look up a specific CVE; it might be a CVE unrelated to YP (eg. package not included, Windows issue). The cve-checker result is a part of the solution, but people also want to know which CVEs do not apply. * CVEs: synchronization of the work on fixes Currently, there is no synchronization; multiple parties might be working on the same fix while nobody is working on another. There might be duplication of work. Ross has https://wiki.yoctoproject.org/wiki/CVE_Status * Triaging of security issues Related to CVE fixes and includes issues reported directly to the YP. Some issues are more likely to be serious for embedded products (attack by network), so not all has the same priority. * Private security communication A way to send a notification of a non-public security issue. For researchers, other projects etc. The security alias exists, but only some people know about its existence. * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. * Documentation Related to visibility. We need easy-to-find documentation of subjects like submitting a CVE fix, reporting a private issue, and how our processes work... This documentation should address people who are not regular contributors. * Additional tooling We could add additional tooling: a template on how to add cve-check to the CI (possibly a different one than the autobuilder), analyze the result, and extend our tooling to their layers... It is also related to the "Architecture" topic below. * Architecture work Security if more than CVE fixes. We also have what is happening in meta-security: hardening, compiler option, secure package configuration, use of code coverage tools, and so on * SRTool We might decide to use it again. It allows one to do much but requires constant commitment. * Presence on pre-notification lists and receiving information before the vulnerability gets public YP currently depends on public data. Principal distributions receive the information before a vulnerability becomes public. It requires (in short) private reporting, a security team, and a track of excellent security record. * Becoming a CNA (be able to assign CVEs) Needed if we want to assign CVEs to the software of the YP, like autobuilder, Toaster etc. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187587): https://lists.openembedded.org/g/openembedded-core/message/187587 Mute This Topic: https://lists.openembedded.org/mt/101334932/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] OE-core CVE metrics for master on Sun 10 Sep 2023 01:00:01 AM HST
On Sun, 10 Sept 2023, 17:14 Khem Raj, wrote: > On Sun, Sep 10, 2023 at 4:18 AM Steve Sakoman wrote: > > > > Branch: master > > > > New this week: 10 CVEs > > CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 * > > CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 * > > These two are addressed in the 5.69 release which is already in > master. So I wonder how the CVE scanner missed it. The NVD entry does not include any version numbers, so all bluez versions are matched as vulnerable. Have you mailed them? Can do it if you haven't. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187457): https://lists.openembedded.org/g/openembedded-core/message/187457 Mute This Topic: https://lists.openembedded.org/mt/101270898/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] linux-yocto: add script to generate kernel CVE_STATUS entries
On Mon, Aug 7, 2023 at 6:28 PM wrote: > From: Ross Burton > > Instead of manually looking up new CVEs and determining what point > releases the fixes are incorporated into, add a script to generate the > CVE_STATUS data automatically. > > First, note that this is very much an interim solution until the > cve-check class fetches data from www.linuxkernelcves.com directly. > > This is coming Ross, this is coming... But I have a question. We do prefer to have a solution that runs completely on the build machine, without automatic rebuilds from the YP? I'm asking because for the solution I'm working on we're adding a pretty big git repo to each build (~130MB). Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185654): https://lists.openembedded.org/g/openembedded-core/message/185654 Mute This Topic: https://lists.openembedded.org/mt/100603502/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][dunfell 00/14] Patch review
On Thu, Jun 22, 2023 at 5:31 PM Steve Sakoman wrote: > Please review this set of changes for dunfell and have comments back by > end of day Monday. > > Passed a-full on autobuilder: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5493 > > The following changes since commit > 77f6fbfa18b4ad77c3756cfdc45d441a20210781: > > build-appliance-image: Update to dunfell head revision (2023-06-17 > 09:47:49 -1000) > > are available in the Git repository at: > > https://git.openembedded.org/openembedded-core-contrib > stable/dunfell-nut > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut > > Abdellatif El Khlifi (1): > kernel-fitimage: adding support for Initramfs bundle and u-boot script > > Andrej Valek (1): > kernel-fitimage: use correct kernel image > > Hitendra Prajapati (1): > openssl: CVE-2023-2650 Possible DoS translating ASN.1 object > identifiers > > Ian Ray (1): > systemd-systemctl: support instance expansion in WantedBy > > Jan Vermaete (1): > cve-update-nvd2-native: added the missing http import > > Marta Rybczynska (1): > cve-update-nvd2-native: new CVE database fetcher > > Martin Siegumfeldt (1): > systemd-systemctl: fix instance template WantedBy symlink construction > > Michael Halstead (4): > uninative: Upgrade to 3.8.1 to include libgcc > uninative: Upgrade to 3.9 to include glibc 2.37 > uninative: Upgrade to 3.10 to support gcc 13 > uninative: Upgrade to 4.0 to include latest gcc 13.1.1 > > Richard Purdie (1): > uninative: Ensure uninative is enabled in all cases for BuildStarted > event > > Sanjay Chitroda (1): > cups: Fix CVE-2023-32324 > > Steve Sakoman (1): > uninative.bbclass: handle read only files outside of patchelf > > meta/classes/cve-check.bbclass| 4 +- > meta/classes/kernel-fitimage.bbclass | 142 ++-- > meta/classes/uninative.bbclass| 4 + > meta/conf/distro/include/yocto-uninative.inc | 10 +- > .../openssl/openssl/CVE-2023-2650.patch | 122 +++ > .../openssl/openssl_1.1.1t.bb | 1 + > .../meta/cve-update-nvd2-native.bb| 334 ++ > .../systemd/systemd-systemctl/systemctl | 8 +- > meta/recipes-extended/cups/cups.inc | 1 + > .../cups/cups/CVE-2023-32324.patch| 36 ++ > 10 files changed, 629 insertions(+), 33 deletions(-) > create mode 100644 > meta/recipes-connectivity/openssl/openssl/CVE-2023-2650.patch > create mode 100644 meta/recipes-core/meta/cve-update-nvd2-native.bb > create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-32324.patch > > Tested this version for the CVE fetcher backport to dunfell, no unexpected issues seen. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185388): https://lists.openembedded.org/g/openembedded-core/message/185388 Mute This Topic: https://lists.openembedded.org/mt/99700025/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone 00/18] Patch review
On Mon, Jun 19, 2023 at 4:55 AM Steve Sakoman wrote: > Please review this set of changes for kirkstone and have comments back by > end of day Tuesday. > > Passed a-full on autobuilder: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5481 > > The following changes since commit > 6e0d694ea1eb5d478dc7508d181c3a820098ee5f: > > uninative: Upgrade to 4.0 to include latest gcc 13.1.1 (2023-06-09 > 06:04:24 -1000) > > are available in the Git repository at: > > https://git.openembedded.org/openembedded-core-contrib > stable/kirkstone-nut > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut > > Andrew Jeffery (1): > Revert "ipk: Decode byte data to string in manifest handling" > > Bruce Ashfield (5): > linux-yocto/5.15: update to v5.15.109 > linux-yocto/5.15: update to v5.15.110 > linux-yocto/5.15: update to v5.15.111 > linux-yocto/5.15: update to v5.15.112 > linux-yocto/5.15: update to v5.15.113 > > Chen Qi (1): > openssh: fix CVE-2023-28531 > > Deepthi Hemraj (1): > glibc: stable 2.35 branch updates > > Ian Ray (1): > systemd-systemctl: support instance expansion in WantedBy > > Jan Vermaete (1): > cve-update-nvd2-native: added the missing http import > > Marta Rybczynska (1): > cve-update-nvd2-native: new CVE database fetcher > > Qiu Tingting (1): > e2fsprogs: fix ptest bug for second running > > Randy MacLeod (1): > vim: upgrade 9.0.1429 -> 9.0.1527 > > Sanjay Chitroda (1): > cups: Fix CVE-2023-32324 > > Yogita Urade (4): > webkitgtk: fix CVE-2022-46691 > webkitgtk: fix CVE-2022-46699 > webkitgtk: fix CVE-2022-42867 > webkitgtk: fix CVE-2022-46700 > > meta/classes/cve-check.bbclass| 4 +- > meta/lib/oe/package_manager/ipk/manifest.py | 2 +- > ...-destination-constraints-for-smartca.patch | 35 ++ > .../openssh/openssh_8.9p1.bb | 1 + > meta/recipes-core/glibc/glibc-version.inc | 2 +- > .../glibc/glibc/CVE-2023-0687.patch | 82 - > meta/recipes-core/glibc/glibc_2.35.bb | 1 - > .../meta/cve-update-nvd2-native.bb| 334 ++ > .../systemd/systemd-systemctl/systemctl | 9 +- > .../e2fsprogs/e2fsprogs/run-ptest | 1 + > .../e2fsprogs/e2fsprogs_1.46.5.bb | 3 + > meta/recipes-extended/cups/cups.inc | 1 + > .../cups/cups/CVE-2023-32324.patch| 36 ++ > .../linux/linux-yocto-rt_5.15.bb | 6 +- > .../linux/linux-yocto-tiny_5.15.bb| 6 +- > meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +- > .../webkit/webkitgtk/CVE-2022-42867.patch | 104 ++ > .../webkit/webkitgtk/CVE-2022-46691.patch | 43 +++ > .../webkit/webkitgtk/CVE-2022-46699.patch | 136 +++ > .../webkit/webkitgtk/CVE-2022-46700.patch | 67 > meta/recipes-sato/webkit/webkitgtk_2.36.8.bb | 4 + > meta/recipes-support/vim/vim.inc | 4 +- > 22 files changed, 792 insertions(+), 115 deletions(-) > create mode 100644 > meta/recipes-connectivity/openssh/openssh/0001-upstream-include-destination-constraints-for-smartca.patch > delete mode 100644 meta/recipes-core/glibc/glibc/CVE-2023-0687.patch > create mode 100644 meta/recipes-core/meta/cve-update-nvd2-native.bb > create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-32324.patch > create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-42867.patch > create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-46691.patch > create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-46699.patch > create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-46700.patch > > > Tested for the CVE fetcher backport to kirkstone, no unexpected issues seen. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185387): https://lists.openembedded.org/g/openembedded-core/message/185387 Mute This Topic: https://lists.openembedded.org/mt/99616177/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [nvd-news] Keyword and Keyword Exact Match Searches Temporarily Disabled
We might see some difficulties in the next days. Marta -- Forwarded message - From: nvd-news Date: Fri, Jul 21, 2023 at 5:57 PM Subject: [nvd-news] Keyword and Keyword Exact Match Searches Temporarily Disabled To: nvd-news *Keyword and Keyword Exact Match Searches Temporarily Disabled* The NVD has been experiencing issues with website and API availability. We have identified the root cause, however, due to the particular complexities and other operational needs, a larger scale solution must be put into place. This will take time to implement and resolve. In the interim, to ensure continuity of services that are not impacted, we will be disabling both the keyword and keyword exact match capabilities of the vulnerability search page and APIs. We are aware that this will impact the daily efforts of many that make use of our data and request understanding and patience while we move towards a viable solution. For questions and concerns you can contact n...@nist.gov . Please refrain from requesting timelines on resolution, we will notify all users through the various channels available when we have information to share on the topic. V/r, The National Vulnerability Database Team -- To unsubscribe from this group, send email to nvd-news+unsubscr...@list.nist.gov View this group at https://list.nist.gov/nvd-news --- To unsubscribe from this group and stop receiving emails from it, send an email to nvd-news+unsubscr...@list.nist.gov. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184704): https://lists.openembedded.org/g/openembedded-core/message/184704 Mute This Topic: https://lists.openembedded.org/mt/100279398/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 v9 0/3] CVE-check handling
On Wed, Jul 19, 2023 at 2:03 PM Andrej Valek via lists.openembedded.org wrote: > Even better, > > So I will make one more rebase, just for "[OE-core][PATCH v9 3/3] > cve_check: > convert CVE_CHECK_IGNORE to CVE_STATUS" > > This version looks best from all I've seen. Let's get it in in this version. I'll have a pachset to fix a few issues after we get multiple fetchers in. I *think* I will be able to use it with multi-fetchers. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184650): https://lists.openembedded.org/g/openembedded-core/message/184650 Mute This Topic: https://lists.openembedded.org/mt/99716038/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][master][mickledore][kirkstone][dunfell][PATCH 1/2] cve-update-nvd2-native: retry all errors and sleep between retries
Thank you Peter for debugging this. Could you dump us a log of one of your
typical runs to see what the errors are?
We might consider mirroring at some point.
Kind regards,
Marta
On Tue, Jul 11, 2023 at 8:37 AM Peter Marko via lists.openembedded.org
wrote:
> From: Peter Marko
>
> Last couple days it is not possible to update NVD DB as servers
> are returning lot of errors.
> Mostly "HTTP Error 503: Service Unavailable" is observed but
> sporadially also some others.
>
> Retrying helps in most cases, so extend retries to all errors.
>
> Additionally add sleep which is recommended by NVD between requests.
> These retries are already implemented between successful requests,
> but giving servers time between failed ones is important, too.
>
> Signed-off-by: Peter Marko
> ---
> meta/recipes-core/meta/cve-update-nvd2-native.bb | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> index 4585126f73..a7392405e0 100644
> --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> @@ -119,6 +119,7 @@ def nvd_request_next(url, api_key, args):
> import urllib.parse
> import gzip
> import http
> +import time
>
> headers = {}
> if api_key:
> @@ -140,13 +141,9 @@ def nvd_request_next(url, api_key, args):
>
> r.close()
>
> -except UnicodeDecodeError:
> -# Received garbage, retry
> -bb.debug(2, "CVE database: received malformed data, retrying
> (request: %s)" %(full_request))
> -pass
> -except http.client.IncompleteRead:
> -# Read incomplete, let's try again
> -bb.debug(2, "CVE database: received incomplete data, retrying
> (request: %s)" %(full_request))
> +except Exception as e:
> +bb.debug(2, "CVE database: received error (%s), retrying
> (request: %s)" %(e, full_request))
> +time.sleep(6)
> pass
> else:
> return raw_data
> --
> 2.30.2
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184136):
https://lists.openembedded.org/g/openembedded-core/message/184136
Mute This Topic: https://lists.openembedded.org/mt/100074006/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][master][mickledore][kirkstone][dunfell][PATCH 2/2] cve-update-nvd2-native: increase retry count
Peter, what is the probability it passes (for the complete download) with those settings? Is it every time? Kind regards, Marta On Tue, Jul 11, 2023 at 1:17 PM Ross Burton wrote: > Horrible, but in my testing it works. Thanks Peter! > > Ross > > > On 11 Jul 2023, at 07:36, Peter Marko via lists.openembedded.org > wrote: > > > > From: Peter Marko > > > > Current 503 errors seem to last several seconds. > > In most cases there are two errors and third request succeeds. > > However sometimes the outage takes more than time needed > > for two retries and third one also fails. > > > > Extend retry count from 3 to 5 to improve the probablity > > that the fetcher succeeds. > > > > Signed-off-by: Peter Marko > > --- > > meta/recipes-core/meta/cve-update-nvd2-native.bb | 2 +- > > 1 file changed, 1 insertion(+), 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 a7392405e0..b3d0038c2f 100644 > > --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb > > +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb > > @@ -129,7 +129,7 @@ def nvd_request_next(url, api_key, args): > > > > full_request = url + '?' + data > > > > -for attempt in range(3): > > +for attempt in range(5): > > try: > > r = urllib.request.urlopen(full_request) > > > > -- > > 2.30.2 > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184134): https://lists.openembedded.org/g/openembedded-core/message/184134 Mute This Topic: https://lists.openembedded.org/mt/100074007/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/4] cve-update-nvd2-native: handle all configuration nodes, not just first
On Fri, 23 Jun 2023, 08:32 , wrote: > From: Ross Burton > > Some CVEs, such as CVE-2013-6629, list multiple configurations which are > vulnerable. The current JSON parser only considers the first > configuration. > > Instead, consider every configuration. We don't yet handle the AND/OR > logical operators, but this is a step in the right direction. > > Signed-off-by: Ross Burton > --- > meta/recipes-core/meta/cve-update-nvd2-native.bb | 9 + > 1 file changed, 5 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 2b585983ac7..0c627ef2623 100644 > --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb > +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb > @@ -323,11 +323,12 @@ def update_db(conn, elt): > [cveId, cveDesc, cvssv2, cvssv3, date, > accessVector]).close() > > try: > -configurations = elt['cve']['configurations'][0]['nodes'] > -for config in configurations: > -parse_node_and_insert(conn, config, cveId) > +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"]: > +parse_node_and_insert(conn, node, cveId) > except KeyError: > -bb.debug(2, "Entry without a configuration") > +bb.debug(2, "CVE %s has no configurations" % cveId) > > do_fetch[nostamp] = "1" > Looks good to me, thank you Ross. Regards, Marta > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183336): https://lists.openembedded.org/g/openembedded-core/message/183336 Mute This Topic: https://lists.openembedded.org/mt/99717256/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Drafting a fetcher for kernelcves
Hello all, I'm drafting a fetcher for kernelcves ( https://github.com/nluedtke/linux_kernel_cves/) and the data conflicts in a certain way with cve-extra-exclusions.inc. With multiple fetchers we'll need to have a way to say which data set has priority. For now I can see examples of two cases (in all cases we go for a specific kernel version): Case one: NVD says unfixed linux_kernel_cves says unknown cve-extra-exclusions.inc says IGNORE Case two: NVD says unfixed linux_kernel_cves says fixed cve-extra-exclusions says IGNORE In the first case, the solutions is IGNORE (some old CVEs), in the second one it's PATCHED. The questions I have: Should cve-extra-exclusions always have priority? Should we allow the user to set priority of fetchers? What I'm going to test is use the kernel_cves fetcher for all kernel CVEs and NVD for all the rest. Should it be an option? I'd like to avoid adding too many options that make cause mistakes... Ideas? Comments? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182413): https://lists.openembedded.org/g/openembedded-core/message/182413 Mute This Topic: https://lists.openembedded.org/mt/99358001/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH] cve-extra-exclusions: add more linux-yocto CVE ignores
On Mon, Jun 5, 2023 at 6:25 PM Ross Burton wrote: > From: Ross Burton > > These CVEs have all been fixed <6.1.30, which is the default linux-yocto > kernel version. > > Those are pretty new ones, should be all covered by the new CVE format. Is anyone already sending pull requests to include that information in the CVE database directly (not NVD)? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182412): https://lists.openembedded.org/g/openembedded-core/message/182412 Mute This Topic: https://lists.openembedded.org/mt/99344319/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH] cve-extra-exclusions: add more linux-yocto CVE ignores
On Mon, Jun 5, 2023 at 6:48 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Mon, 2023-06-05 at 16:31 +, Ross Burton wrote: > > I did some triage of the CVEs in this list but realised that this > > file is a bad location for them: whilst we don’t expect people to > > switch out most recipes, we do have to expect BSPs to switch the > > kernel, so by accumulating a list of exclusions in this recipe that > > are based on the current version of linux-yocto we may negatively > > impact on people using a BSP which, for example, uses a 5.10 kernel. > > > > Should we move the kernel-specific exclusions, where they’re being > > done because they’re fixed in a release we ship, to the linux-yocto > > recipe? > > A specific include with "6.1" in the name might be a good way to do it > so that others who follow the same stable series updates could reuse > it? > > This is definitely better to have a specific file. However, I know some BSPs that stay at x.0 version of the kernel and if they include such a file, they will have a false sense of security... Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182411): https://lists.openembedded.org/g/openembedded-core/message/182411 Mute This Topic: https://lists.openembedded.org/mt/99344319/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Clarifying CVEs for NVD (Was: Re: [OE-core] [PATCH] cve-extra-exclusions: ignore inapplicable linux-yocto CVEs)
Hello all, I'm in process of clarifying entries for NVD to have them fixed in the sources. The comments in the patch linked do not include all the needed information, however. Let's take this one: +# https://nvd.nist.gov/vuln/detail/CVE-2022-1462 +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 +# Patched in kernel since v5.19 a501ab75e7624d133a5a3c7ec010687c8b961d23 +# Backported in version v5.4.208 f7785092cb7f022f59ebdaa181651f7c877df132 +# Backported in version v5.10.134 08afa87f58d83dfe040572ed591b47e8cb9e225c +# Backported in version v5.15.58 b2d1e4cd558cffec6bfe318f5d74e6cffc374d29 +CVE_CHECK_IGNORE += "CVE-2022-1462" We need to write a set of rules on which versions are vulnerable, like this: [v2.6.12 - v5.4.208] [v5.5.0 ??? - v5.10.134] [v5.11.0 ??? - v5.15.58] [v5.16.0 ??? - v5.19.0] The values with ??? are uncertain. Geoffrey, Yann, as it was scripted out according to one of the discussions, are you able to confirm those "starting" versions ? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182410): https://lists.openembedded.org/g/openembedded-core/message/182410 Mute This Topic: https://lists.openembedded.org/mt/99357871/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Cve database updates status
Hello all, A short heads-up on the situation with CVE updates. 1. In the new CVE database, each fix needs to be made by the CNA that created the entry. For the kernel ones there are several. Will try a test fix (at random) to see what the reaction could be. 2. I do not have an answer from NVD yet, but I missed the fact that we have a US holiday in the process. I'm sending another request today, with a different format and let's wait till the end of the week (I would like to have the clarification on their import from the new CVE data). Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181921): https://lists.openembedded.org/g/openembedded-core/message/181921 Mute This Topic: https://lists.openembedded.org/mt/99218793/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone 04/15] linux-yocto: Exclude 121 CVEs already fixed upstream
On Thu, May 11, 2023 at 11:17 PM Armin Kuster wrote: > > > On 5/9/23 6:32 PM, Steve Sakoman wrote: > > From: Yoann Congal > > > > Exclude CVEs that are fixed in both current linux-yocto version > > v5.10.175 and v5.15.108. > > > > To get the commit fixing a CVE, I used the Debian kernel-sec repo [1]. > > > > [1]: > https://salsa.debian.org/kernel-team/kernel-sec/-/commit/86d5040aee9275f9555458fcaf9cb43710dff398 > > Just a cautionary note: If anyone is including linux-yocto.inc in their > custom kernel recipes based on the same kernel version but have not > updated past the dot release Yocto has, you wont know you are missing > fixes. > > I don't know how we advise the proper use of linux-yocto.inc? > Most of those should be in the NVD database and not included this way. While working on the new featcher, I was also considering a multiple fetcher configuration. Originally to allow OSV and such. But also, an additional "fetcher" could contain entries where we want to override the NVD database. IMO that would be a cleaner solution and would allow safer include of the complete fix file, because it will be always checked to the actual package version. What do you think about it? Worth a POC? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181557): https://lists.openembedded.org/g/openembedded-core/message/181557 Mute This Topic: https://lists.openembedded.org/mt/98795092/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 v3 1/3] cve-check: add option to add additional patched CVEs
Thank you for this work. I think we are going in a good direction. My
comments in the text.
In general, I would like that we come with the fixed list of possible
statuses and avoid adding new ones too frequently. Changing them will break
my parsing and status scripts each time.
On Fri, May 19, 2023 at 8:24 AM Andrej Valek via lists.openembedded.org
wrote:
> - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
> more flexible. CVE_STATUS should contain flag for each CVE with accepted
> values "Ignored", "Not applicable" or "Patched". It allows to add
> a status for each CVEs.
>
I'm missing a status to cover the situation when the NVD (or any other
database) has an incorrect entry. We have quite many of those. This might
be a temporary situation, but not always.
SPDX (the 3.0 draft) has some other possible reasons
https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md
What looks like interesting ideas are:
* "Can't fix" / "Will not fix"
* "Not applicable" (SPDX language: Ineffective) when the code is not used
* "Invalid match" (this is our NVD mismatch case)
* "Mitigated" measures taken so that it cannot be exploited
* "Workarounded"
There is still one big missing part: related to configuration options. It
could be used with "Not applicable"/"Ineffective" code, but only in cases
where it is not possible to activate the code. If the user can switch
between vulnerable/not vulnerable versions by a packageconfig change or so,
this is not covered.
Addiional question: why CVE_STATUS_REASONING and not CVE_STATUS_REASON ?
(reason variable is used nearly everywhere)
> diff --git a/meta/classes/cve-check.bbclass
> b/meta/classes/cve-check.bbclass
> index bd9e7e7445c..44462de7445 100644
> --- a/meta/classes/cve-check.bbclass
> +++ b/meta/classes/cve-check.bbclass
> @@ -70,12 +70,15 @@ CVE_CHECK_COVERAGE ??= "1"
> # Skip CVE Check for packages (PN)
> CVE_CHECK_SKIP_RECIPE ?= ""
>
> -# Ingore the check for a given list of CVEs. If a CVE is found,
> -# then it is considered patched. The value is a string containing
> -# space separated CVE values:
> +# Replace NVD DB check status for a given CVE. Each of CVE has to be
> mentioned
> +# separately with optional reason for this status.
> #
> -# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
> +# CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
> +# CVE_STATUS[CVE-1234-0002] = "Not applicable"
> +# CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
> #
> +# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
> +# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
> CVE_CHECK_IGNORE ?= ""
>
> # Layers to be excluded
> @@ -88,6 +91,25 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
> # set to "alphabetical" for version using single alphabetical character
> as increment release
> CVE_VERSION_SUFFIX ??= ""
>
> +python () {
> +# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
> +cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
> +if cve_check_ignore:
> +bb.warn("CVE_CHECK_IGNORE has been deprecated, use CVE_STATUS
> instead")
> +set_cves_statuses(d, d.getVar("CVE_CHECK_IGNORE"), "Ignored")
> +
> +# Process CVE_STATUS_GROUPS to set multiple statuses and optional
> reasons at once
> +for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
> +set_cves_statuses(d, d.getVar(cve_status_group) or "",
> + d.getVarFlag(cve_status_group, "status"),
> + d.getVarFlag(cve_status_group, "reason"))
> +}
> +
> +def set_cves_statuses(d, cves, status, reason=""):
> +for cve in cves.split():
> +d.setVarFlag("CVE_STATUS", cve, status)
> +d.setVarFlag("CVE_STATUS_REASONING", cve, reason)
> +
> def generate_json_report(d, out_path, link_path):
> if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
> import json
> @@ -282,7 +304,13 @@ def check_cves(d, patched_cves):
> bb.note("Recipe has been skipped by cve-check")
> return ([], [], [], [])
>
> -cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
> +# Convert CVE_STATUS into ignored CVEs and check validity
> +cve_ignore = []
> +for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
> +if status in ["Not applicable", "Ignored"]:
> +cve_ignore.append(cve)
> +elif status not in ["Patched"]:
> +bb.error("Unsupported status %s in CVE_STATUS[%s]" % (status,
> cve))
>
I do not see this entry added into the "Patched" list.
IMO would be better to handle Patched separately, and so a complete "else"
for all other reasons. Allows to avoid hard-coding all possible options.
>
> import sqlite3
> db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
> @@ -455,6 +483,9 @@ def cve_write_data_text(d, patched, unpatched,
> ignored, cve_data):
> else:
>
Re: [OE-core] [PATCH] cve-update-nvd2-native: new CVE database fetcher
On Wed, Apr 5, 2023 at 8:44 PM Steve Sakoman wrote: > On Wed, Apr 5, 2023 at 8:43 AM Marta Rybczynska > wrote: > > > > > > > > On Wed, Apr 5, 2023 at 5:55 PM Steve Sakoman wrote: > >> > >> Hi Marta, > >> > >> Is this safe to backport to the stable branches, or should I let it > >> "age" in master for a while? > >> > > > > Hi Steve, > > I vote to let it age for a little moment. In the meantime I'm trying to > figure out when exactly NVD will turn off the old database. > > OK, will do! > I have received a confirmation from the NVD that they are currently planning to turn off teh old feed in *September 2023*. We have time to stabilize then. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181044): https://lists.openembedded.org/g/openembedded-core/message/181044 Mute This Topic: https://lists.openembedded.org/mt/97925018/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] cve-update-nvd2-native: added the missing http import
On Wed, Apr 12, 2023 at 3:19 PM Yoann Congal wrote: > On 4/12/23 13:45, jan vermaete wrote: > > Hi, > > > > I have no preference on how to fix it. > > I intended to stay as close as possible to the code of Marta > > Yes, I see that. I'm okay with your patch as-is since the current code is > not coherent. > > But, I don't see how we can get this exception from urllib... Maybe > someone with more knowledge in urllib can tell us? > > I'm OK to add the import http. If you remove the except block, you will get errors from time to time (in my setup most of the time when you do a complete download). Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179955): https://lists.openembedded.org/g/openembedded-core/message/179955 Mute This Topic: https://lists.openembedded.org/mt/98216121/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] cve-update-nvd2-native: new CVE database fetcher
On Wed, Apr 5, 2023 at 5:55 PM Steve Sakoman wrote: > Hi Marta, > > Is this safe to backport to the stable branches, or should I let it > "age" in master for a while? > > Hi Steve, I vote to let it age for a little moment. In the meantime I'm trying to figure out when exactly NVD will turn off the old database. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179746): https://lists.openembedded.org/g/openembedded-core/message/179746 Mute This Topic: https://lists.openembedded.org/mt/97925018/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] Fix cve-check false negative
Hello Geoffrey, Would it be possible to run it over the world build of oe-core and possibly meta-oe ? My build farm will be available only next week and I would like to know if there are unexpected changes. Kind regards, Marta On Wed, Mar 29, 2023 at 3:31 PM Geoffrey GIRY wrote: > Hello Marta, > > We only tested core-image-minimal and some recipes that use the update > and release candidate formats (pX and -rcX) > > Geoffrey GIRY > SMILE ECS - R Engineer > > Le mer. 29 mars 2023 à 06:45, Marta Rybczynska a > écrit : > > > > On Tue, Mar 28, 2023 at 12:24 PM Geoffrey GIRY > wrote: > >> > >> Fixes [YOCTO #14127] > >> > >> NVD DB store version and update in the same value, separated by '_'. > >> The proposed patch check if the version from NVD DB contains a "_", > >> ie 9.2.0_p1 is convert to 9.2.0p1 before version comparison. > >> > > > > Thank you for the patch. Which layers (and world builds) have you > verified it with? > > I'm asking because versioning is always a complicated problems with > frequent exceptions to all "rules". > > > > Kind regards, > > Marta > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179402): https://lists.openembedded.org/g/openembedded-core/message/179402 Mute This Topic: https://lists.openembedded.org/mt/97902020/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] cve-update-nvd2-native: new CVE database fetcher
On Wed, 29 Mar 2023, 12:03 Marta Rybczynska via lists.openembedded.org, wrote: > Add new fetcher for the NVD database using the 2.0 API [1]. > The implementation changes as little as possible, keeping the current > database format (but using a different database file for the transition > period), with a notable exception of not using the META table. > > Minor changes that could be visible: > - the database starts in 1999 instead of 2002 > - the complete fetch is longer (30 minutes typically) > Ross, Richard, This is the most up-to-date version with urllib and all download errors I managed to run into. Kind regards Marta > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179301): https://lists.openembedded.org/g/openembedded-core/message/179301 Mute This Topic: https://lists.openembedded.org/mt/97925018/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] cve-update-nvd2-native: new CVE database fetcher
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
Signed-off-by: Marta Rybczynska
---
meta/classes/cve-check.bbclass| 4 +-
.../meta/cve-update-nvd2-native.bb| 333 ++
2 files changed, 335 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/meta/cve-update-nvd2-native.bb
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 41fdf8363f..1f16683c32 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -32,7 +32,7 @@ CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_1.1.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
CVE_CHECK_LOG ?= "${T}/cve.log"
@@ -161,7 +161,7 @@ python do_cve_check () {
}
addtask cve_check before do_build
-do_cve_check[depends] = "cve-update-db-native:do_fetch"
+do_cve_check[depends] = "cve-update-nvd2-native:do_fetch"
do_cve_check[nostamp] = "1"
python cve_check_cleanup () {
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
new file mode 100644
index 00..1c14481c21
--- /dev/null
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -0,0 +1,333 @@
+SUMMARY = "Updates the NVD CVE database"
+LICENSE = "MIT"
+
+# Important note:
+# This product uses the NVD API but is not endorsed or certified by the NVD.
+
+INHIBIT_DEFAULT_DEPS = "1"
+
+inherit native
+
+deltask do_unpack
+deltask do_patch
+deltask do_configure
+deltask do_compile
+deltask do_install
+deltask do_populate_sysroot
+
+NVDCVE_URL ?= "https://services.nvd.nist.gov/rest/json/cves/2.0;
+
+# CVE database update interval, in seconds. By default: once a day (24*60*60).
+# Use 0 to force the update
+# Use a negative value to skip the update
+CVE_DB_UPDATE_INTERVAL ?= "86400"
+
+# Timeout for blocking socket operations, such as the connection attempt.
+CVE_SOCKET_TIMEOUT ?= "60"
+
+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.")
+}
+
+python do_fetch() {
+"""
+Update NVD database with API 2.0
+"""
+import bb.utils
+import bb.progress
+import shutil
+
+bb.utils.export_proxies(d)
+
+db_file = d.getVar("CVE_CHECK_DB_FILE")
+db_dir = os.path.dirname(db_file)
+db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
+
+cleanup_db_download(db_file, db_tmp_file)
+# By default let's update the whole database (since time 0)
+database_time = 0
+
+# The NVD database changes once a day, so no need to update more frequently
+# Allow the user to force-update
+try:
+import time
+update_interval = int(d.getVar("CVE_DB_UPDATE_INTERVAL"))
+if update_interval < 0:
+bb.note("CVE database update skipped")
+return
+if time.time() - os.path.getmtime(db_file) < update_interval:
+bb.note("CVE database recently updated, skipping")
+return
+database_time = os.path.getmtime(db_file)
+
+except OSError:
+pass
+
+bb.utils.mkdirhier(db_dir)
+if os.path.exists(db_file):
+shutil.copy2(db_file, db_tmp_file)
+
+if update_db_file(db_tmp_file, d, database_time) == True:
+# Update downloaded correctly, can swap files
+shutil.move(db_tmp_file, db_file)
+else:
+# Update failed, do not modify the database
+bb.warn("CVE database update failed")
+os.remove(db_tmp_file)
+}
+
+do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[file-checksums] = ""
+do_fetch[vardeps] = ""
+
+def cleanup_db_download(db_file, db_tmp_file):
+"""
+Cleanup the download space from possible failed downloads
+"""
+
+# Clean up the updates done on the main file
+# Remove it only if a journal file exists - it means a complete re-download
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is prese
Re: [OE-core] [PATCH] Fix cve-check false negative
On Tue, Mar 28, 2023 at 12:24 PM Geoffrey GIRY wrote: > Fixes [YOCTO #14127] > > NVD DB store version and update in the same value, separated by '_'. > The proposed patch check if the version from NVD DB contains a "_", > ie 9.2.0_p1 is convert to 9.2.0p1 before version comparison. > > Thank you for the patch. Which layers (and world builds) have you verified it with? I'm asking because versioning is always a complicated problems with frequent exceptions to all "rules". Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179260): https://lists.openembedded.org/g/openembedded-core/message/179260 Mute This Topic: https://lists.openembedded.org/mt/97902020/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] Cve fetcher update
On Wed, Feb 22, 2023 at 11:08 AM Marta Rybczynska via lists.openembedded.org wrote: > > > On Tue, Feb 21, 2023 at 2:47 PM Ross Burton wrote: > >> Hi Marta, >> >> > On 21 Feb 2023, at 13:20, Marta Rybczynska >> wrote: >> > I'm finishing the new fetcher for cve check using the 2.0 NVD API. Will >> need testers to check as many configurations as possible before we switch >> the format. >> > >> > The current estimate is this week, hoping that the real life doesn't >> interfere. >> > >> > Good news for all users is that nothing changes for you. Results should >> be compatible. The one noticeable thing is that the complete fetch is >> longer than before. >> >> Awesome, thanks Marta. I’ll happily review and test the code. >> >> How long is a complete fetch now? My very rough testing when I first >> looked at the new API suggested 30 minutes for a full sync. >> >> > Thanks Ross. The fetcher now has the recommended 6 seconds wait so it is > long - but a similar time you had (around 30 min). It seems that in > practice it does not change much - the rate limiting is on the server side. > This being said, there is only my instance now, when there will be many > more, it could change. > > > Hello Ross, Have you finished your review? The new version that is under test in my systems right now is using urllib. I'm wondering what was your other feedback. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179229): https://lists.openembedded.org/g/openembedded-core/message/179229 Mute This Topic: https://lists.openembedded.org/mt/97108178/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC]] cve-update-nvd2-native: new CVE database fetcher
On Fri, Feb 24, 2023 at 5:22 PM Marta Rybczynska via lists.openembedded.org wrote: > > > On Fri, Feb 24, 2023 at 5:16 PM Marta Rybczynska > wrote: > >> Add new fetcher for the NVD database using the 2.0 API [1]. >> The implementation changes as little as possible, keeping the current >> database format (but using a different database file for the transition >> period), with a notable exception of not using the META table. >> >> Minor changes that could be visible: >> - the database starts in 1999 instead of 2002 >> - the complete fetch is longer (30 minutes typically) >> >> > Tests VERY MUCH welcome, I have found some bugs today still. > > Docs (with a mandatory note according to the terms of use) will come with > v2. > > For the swap between v1 and v2 I'm not sure what will be the best solution: > - a configuration option allows to migrate when the user decides to do so > - ... but does not protect the day they disconnect the feed > > What do you think? > > Still interested in your opinions on this. Currently I'm investigating some differences between both fetchers. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178492): https://lists.openembedded.org/g/openembedded-core/message/178492 Mute This Topic: https://lists.openembedded.org/mt/97209064/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] cve-extra-exclusions: ignore inapplicable linux-yocto CVEs
Thank you for the explanation and the work done. Could you contact me off list so that we confirm what and where was send? 14 days is longer than I've ever had as a response time from NVD. Kind regards Marta On Tue, 28 Feb 2023, 10:05 Geoffrey GIRY, wrote: > Hello Marta, Richard, > > We sent to NVD an update for one CVE (CVE-2020-27784) 14 days ago, we > are still waiting for an answer. > This is the first time we ever do this, so we did send only the first as a > test. > When the change is accepted, we will send updates requests for each > already patched CVE. > > Richard, thank you for the details provided. > > Regards, > Geoffrey GIRY > Research and Development Engineer > SMILE > > > > Le lun. 27 févr. 2023 à 23:02, Richard Purdie > a écrit : > > > > On Mon, 2023-02-27 at 18:49 +0100, Marta Rybczynska wrote: > > > Thank you for the work. Have you contacted NVD to update the database > > > instead? What did they say? > > > > Ideally a large portion of these should be sent to NVD but we did talk > > a little about the on the call last week. We agreed that it will take > > time and it was better to document this and fix our reporting in the > > meantime as well as share these useful details more widely. I'd suggest > > that as things are submitted we could document that, hopefully we'll > > also be able to remove many of these entries. > > > > I'm sure Geoffrey can provide more status but I wanted to update on why > > this was sent and why I think we should take it. > > > > I will drop the kernel filtering so new kernel CVEs then show up in all > > our metrics going forward. > > > > Cheers, > > > > Richard > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177857): https://lists.openembedded.org/g/openembedded-core/message/177857 Mute This Topic: https://lists.openembedded.org/mt/97263529/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] cve-extra-exclusions: ignore inapplicable linux-yocto CVEs
Hello Geoffroy, Thank you for the work. Have you contacted NVD to update the database instead? What did they say? Kind regards Marta On Mon, 27 Feb 2023, 12:00 Geoffrey GIRY, wrote: > Multiple CVE are patched in kernel but appears as active because the NVD > database is not up to date. > > CVE are ignored if and only if all versions of kernel used by master are > patched. > > Also ignore CVEs with wrong CPE (applied to kernel but actually are for > another package) > > Signed-off-by: Geoffrey GIRY > Reviewed-by: Yoann Congal > --- > .../distro/include/cve-extra-exclusions.inc | 296 ++ > 1 file changed, 296 insertions(+) > > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc > b/meta/conf/distro/include/cve-extra-exclusions.inc > index 8b5f8d49b8..a281a8ac65 100644 > --- a/meta/conf/distro/include/cve-extra-exclusions.inc > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc > @@ -78,9 +78,34 @@ CVE_CHECK_IGNORE += "CVE-2018-126 CVE-2018-10840 > CVE-2018-10876 CVE-2018-108 > CVE_CHECK_IGNORE += "CVE-2019-10126 CVE-2019-14899 CVE-2019-18910 > CVE-2019-3016 CVE-2019-3819 CVE-2019-3846 CVE-2019-3887" > # 2020 > CVE_CHECK_IGNORE += "CVE-2020-10732 CVE-2020-10742 CVE-2020-16119 > CVE-2020-1749 CVE-2020-25672 CVE-2020-27820 CVE-2020-35501 CVE-2020-8834" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2020-27784 > +# Introduced in version v4.1 b26394bd567e5ebe57ec4dee7fe6cd14023c96e9 > +# Patched in kernel since v5.10 > e8d5f92b8d30bb4ade76494490c3c065e12411b1 > +# Backported in version v5.4.73 > e9e791f5c39ab30e374a3b1a9c25ca7ff24988f3 > +CVE_CHECK_IGNORE += "CVE-2020-27784" > + > # 2021 > CVE_CHECK_IGNORE += "CVE-2021-20194 CVE-2021-20226 CVE-2021-20265 > CVE-2021-3564 CVE-2021-3743 CVE-2021-3847 CVE-2021-4002 \ > CVE-2021-4090 CVE-2021-4095 CVE-2021-4197 > CVE-2021-4202 CVE-2021-44879 CVE-2021-45402" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2021-3669 > +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > +# Patched in kernel since v5.15 20401d1058f3f841f35a594ac2fc1293710e55b9 > +CVE_CHECK_IGNORE += "CVE-2021-3669" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2021-3759 > +# Introduced in version v4.5 a9bb7e620efdfd29b6d1c238041173e411670996 > +# Patched in kernel since v5.15 18319498fdd4cdf8c1c2c48cd432863b1f915d6f > +# Backported in version v5.4.224 bad83d55134e647a739ebef2082541963f2cbc92 > +# Backported in version v5.10.154 836686e1a01d7e2fda6a5a18252243ff30a6e196 > +CVE_CHECK_IGNORE += "CVE-2021-3759" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2021-4218 > +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > +# Patched in kernel since v5.8 32927393dc1ccd60fb2bdc05b9e8e88753761469 > +CVE_CHECK_IGNORE += "CVE-2021-4218" > + > # 2022 > CVE_CHECK_IGNORE += "CVE-2022-0185 CVE-2022-0264 CVE-2022-0286 > CVE-2022-0330 CVE-2022-0382 CVE-2022-0433 CVE-2022-0435 \ > CVE-2022-0492 CVE-2022-0494 CVE-2022-0500 > CVE-2022-0516 CVE-2022-0617 CVE-2022-0742 CVE-2022-0854 \ > @@ -90,6 +115,277 @@ CVE_CHECK_IGNORE += "CVE-2022-0185 CVE-2022-0264 > CVE-2022-0286 CVE-2022-0330 CVE > CVE-2022-28356 CVE-2022-28388 CVE-2022-28389 > CVE-2022-28390 CVE-2022-28796 CVE-2022-28893 CVE-2022-29156 \ > CVE-2022-29582 CVE-2022-29968" > > +# https://nvd.nist.gov/vuln/detail/CVE-2022-0480 > +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > +# Patched in kernel since v5.15 0f12156dff2862ac54235fc72703f18770769042 > +CVE_CHECK_IGNORE += "CVE-2022-0480" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-1184 > +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > +# Patched in kernel since v5.19 46c116b920ebec58031f0a78c5ea9599b0d2a371 > +# Backported in version v5.4.198 17034d45ec443fb0e3c0e7297f9cd10f70446064 > +# Backported in version v5.10.121 da2f05919238c7bdc6e28c79539f55c8355408bb > +# Backported in version v5.15.46 ca17db384762be0ec38373a12460081d22a8b42d > +CVE_CHECK_IGNORE += "CVE-2022-1184" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-1462 > +# Introduced in version v2.6.12 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > +# Patched in kernel since v5.19 a501ab75e7624d133a5a3c7ec010687c8b961d23 > +# Backported in version v5.4.208 f7785092cb7f022f59ebdaa181651f7c877df132 > +# Backported in version v5.10.134 08afa87f58d83dfe040572ed591b47e8cb9e225c > +# Backported in version v5.15.58 b2d1e4cd558cffec6bfe318f5d74e6cffc374d29 > +CVE_CHECK_IGNORE += "CVE-2022-1462" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-2308 > +# Introduced in version v5.15 c8a6153b6c59d95c0e091f053f6f180952ade91e > +# Patched in kernel since v6.0 46f8a29272e51b6df7393d58fc5cb8967397ef2b > +# Backported in version v5.15.72 dc248ddf41eab4566e95b1ee2433c8a5134ad94a > +# Backported in version v5.19.14 38d854c4a11c3bbf6a96ea46f14b282670c784ac > +CVE_CHECK_IGNORE += "CVE-2022-2308" > + > +#
Re: [OE-core] [RFC]] cve-update-nvd2-native: new CVE database fetcher
On Fri, Feb 24, 2023 at 5:16 PM Marta Rybczynska wrote: > Add new fetcher for the NVD database using the 2.0 API [1]. > The implementation changes as little as possible, keeping the current > database format (but using a different database file for the transition > period), with a notable exception of not using the META table. > > Minor changes that could be visible: > - the database starts in 1999 instead of 2002 > - the complete fetch is longer (30 minutes typically) > > Tests VERY MUCH welcome, I have found some bugs today still. Docs (with a mandatory note according to the terms of use) will come with v2. For the swap between v1 and v2 I'm not sure what will be the best solution: - a configuration option allows to migrate when the user decides to do so - ... but does not protect the day they disconnect the feed What do you think? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177693): https://lists.openembedded.org/g/openembedded-core/message/177693 Mute This Topic: https://lists.openembedded.org/mt/97209064/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC]] cve-update-nvd2-native: new CVE database fetcher
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
Signed-off-by: Marta Rybczynska
---
meta/classes/cve-check.bbclass| 4 +-
.../meta/cve-update-nvd2-native.bb| 300 ++
2 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/meta/cve-update-nvd2-native.bb
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 41fdf8363f..1f16683c32 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -32,7 +32,7 @@ CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_1.1.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
CVE_CHECK_LOG ?= "${T}/cve.log"
@@ -161,7 +161,7 @@ python do_cve_check () {
}
addtask cve_check before do_build
-do_cve_check[depends] = "cve-update-db-native:do_fetch"
+do_cve_check[depends] = "cve-update-nvd2-native:do_fetch"
do_cve_check[nostamp] = "1"
python cve_check_cleanup () {
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
new file mode 100644
index 00..5f2e962dc7
--- /dev/null
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -0,0 +1,300 @@
+SUMMARY = "Updates the NVD CVE database"
+LICENSE = "MIT"
+
+# Important note:
+# This product uses the NVD API but is not endorsed or certified by the NVD.
+
+INHIBIT_DEFAULT_DEPS = "1"
+
+inherit native
+
+deltask do_unpack
+deltask do_patch
+deltask do_configure
+deltask do_compile
+deltask do_install
+deltask do_populate_sysroot
+
+NVDCVE_URL ?= "https://services.nvd.nist.gov/rest/json/cves/2.0;
+
+# CVE database update interval, in seconds. By default: once a day (24*60*60).
+# Use 0 to force the update
+# Use a negative value to skip the update
+CVE_DB_UPDATE_INTERVAL ?= "86400"
+
+# Timeout for blocking socket operations, such as the connection attempt.
+CVE_SOCKET_TIMEOUT ?= "60"
+
+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.")
+}
+
+python do_fetch() {
+"""
+Update NVD database with API 2.0
+"""
+import bb.utils
+import bb.progress
+import shutil
+
+bb.utils.export_proxies(d)
+
+db_file = d.getVar("CVE_CHECK_DB_FILE")
+db_dir = os.path.dirname(db_file)
+db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
+
+cleanup_db_download(db_file, db_tmp_file)
+# By default let's update the whole database (since time 0)
+database_time = 0
+
+# The NVD database changes once a day, so no need to update more frequently
+# Allow the user to force-update
+try:
+import time
+update_interval = int(d.getVar("CVE_DB_UPDATE_INTERVAL"))
+if update_interval < 0:
+bb.note("CVE database update skipped")
+return
+if time.time() - os.path.getmtime(db_file) < update_interval:
+bb.note("CVE database recently updated, skipping")
+return
+database_time = os.path.getmtime(db_file)
+
+except OSError:
+pass
+
+bb.utils.mkdirhier(db_dir)
+if os.path.exists(db_file):
+shutil.copy2(db_file, db_tmp_file)
+
+if update_db_file(db_tmp_file, d, database_time) == True:
+# Update downloaded correctly, can swap files
+shutil.move(db_tmp_file, db_file)
+else:
+# Update failed, do not modify the database
+bb.note("CVE database update failed")
+os.remove(db_tmp_file)
+}
+
+do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[file-checksums] = ""
+do_fetch[vardeps] = ""
+
+def cleanup_db_download(db_file, db_tmp_file):
+"""
+Cleanup the download space from possible failed downloads
+"""
+
+# Clean up the updates done on the main file
+# Remove it only if a journal file exists - it means a complete re-download
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is prese
Re: [OE-core] Cve fetcher update
On Tue, Feb 21, 2023 at 2:47 PM Ross Burton wrote: > Hi Marta, > > > On 21 Feb 2023, at 13:20, Marta Rybczynska wrote: > > I'm finishing the new fetcher for cve check using the 2.0 NVD API. Will > need testers to check as many configurations as possible before we switch > the format. > > > > The current estimate is this week, hoping that the real life doesn't > interfere. > > > > Good news for all users is that nothing changes for you. Results should > be compatible. The one noticeable thing is that the complete fetch is > longer than before. > > Awesome, thanks Marta. I’ll happily review and test the code. > > How long is a complete fetch now? My very rough testing when I first > looked at the new API suggested 30 minutes for a full sync. > > Thanks Ross. The fetcher now has the recommended 6 seconds wait so it is long - but a similar time you had (around 30 min). It seems that in practice it does not change much - the rate limiting is on the server side. This being said, there is only my instance now, when there will be many more, it could change. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177563): https://lists.openembedded.org/g/openembedded-core/message/177563 Mute This Topic: https://lists.openembedded.org/mt/97108178/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Cve fetcher update
Hello all, I'm finishing the new fetcher for cve check using the 2.0 NVD API. Will need testers to check as many configurations as possible before we switch the format. The current estimate is this week, hoping that the real life doesn't interfere. Good news for all users is that nothing changes for you. Results should be compatible. The one noticeable thing is that the complete fetch is longer than before. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177495): https://lists.openembedded.org/g/openembedded-core/message/177495 Mute This Topic: https://lists.openembedded.org/mt/97108178/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-db-native: avoid partial updates
> > >>> >>> Hi Jose, >>> Thanks for looking into that. The function is not a total duplicate: the >>> difference is that >>> the it always removes the db_tmp_file, not only if the journal file >>> exists (Python code >>> formatting!). >>> >> >> Don't see on the first time that the db_tmp_file is always removed, I >> need new glasses :) >> >> >>> >>> I was hesitating on this part a bit, because with the old path could be >>> taken only in some >>> specific situations: at the code update and if you share the DL_DIR and >>> some of the builds >>> use the old code, some the new version. I think we should keep both for >>> now for safety. >>> >> >> makes sense, thanks for your explanation. >> >> > Well... I'll submit a v2 with comments to make sure nobody tries to > optimize that piece :) > And here it is (with a minor title change): https://lists.openembedded.org/g/openembedded-core/message/175355 Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175486): https://lists.openembedded.org/g/openembedded-core/message/175486 Mute This Topic: https://lists.openembedded.org/mt/96002809/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 1/2] cve-update-db-native: move download cleanup to a function
This patch is replaced by
https://lists.openembedded.org/g/openembedded-core/message/175355 (with a
minor patch title change)
On Mon, Jan 2, 2023 at 8:03 AM Marta Rybczynska
wrote:
> Move cleanup of the database after a failed download to a separate
> function. This will be useful when we have more actions to do in
> that situation.
>
> Signed-off-by: Marta Rybczynska
> ---
> meta/recipes-core/meta/cve-update-db-native.bb | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
> b/meta/recipes-core/meta/cve-update-db-native.bb
> index 9b9dbbd75f..642fda5395 100644
> --- a/meta/recipes-core/meta/cve-update-db-native.bb
> +++ b/meta/recipes-core/meta/cve-update-db-native.bb
> @@ -44,13 +44,7 @@ python do_fetch() {
>
> cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
>
> -if os.path.exists("{0}-journal".format(db_file)):
> -# If a journal is present the last update might have been
> interrupted. In that case,
> -# just wipe any leftovers and force the DB to be recreated.
> -os.remove("{0}-journal".format(db_file))
> -
> -if os.path.exists(db_file):
> -os.remove(db_file)
> +cleanup_db_download(db_file)
>
> # The NVD database changes once a day, so no need to update more
> frequently
> # Allow the user to force-update
> @@ -134,6 +128,15 @@ do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
> do_fetch[file-checksums] = ""
> do_fetch[vardeps] = ""
>
> +def cleanup_db_download(db_file):
> +if os.path.exists("{0}-journal".format(db_file)):
> +# If a journal is present the last update might have been
> interrupted. In that case,
> +# just wipe any leftovers and force the DB to be recreated.
> +os.remove("{0}-journal".format(db_file))
> +
> +if os.path.exists(db_file):
> +os.remove(db_file)
> +
> def initialize_db(conn):
> with conn:
> c = conn.cursor()
> --
> 2.35.1
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175485):
https://lists.openembedded.org/g/openembedded-core/message/175485
Mute This Topic: https://lists.openembedded.org/mt/96002806/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]] cve-update-db-native: avoid incomplete updates
The database update has been done on the original file. In case of
network connection issues, temporary outage of the NVD server or
a similar situation, the function could exit with incomplete data
in the database. This patch solves the issue by performing the update
on a copy of the database. It replaces the main one only if the whole
update was successful.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
Reported-by: Alberto Pianon
Signed-off-by: Marta Rybczynska
---
.../recipes-core/meta/cve-update-db-native.bb | 83 ++-
1 file changed, 61 insertions(+), 22 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 9b9dbbd75f..079f062f79 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
# Timeout for blocking socket operations, such as the connection attempt.
CVE_SOCKET_TIMEOUT ?= "60"
+CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
+
python () {
if not bb.data.inherits_class("cve-check", d):
raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not
loaded.")
@@ -32,25 +34,15 @@ python do_fetch() {
"""
import bb.utils
import bb.progress
-import sqlite3, urllib, urllib.parse, gzip
-from datetime import date
+import shutil
bb.utils.export_proxies(d)
-YEAR_START = 2002
-
db_file = d.getVar("CVE_CHECK_DB_FILE")
db_dir = os.path.dirname(db_file)
+db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
-cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
-
-if os.path.exists("{0}-journal".format(db_file)):
-# If a journal is present the last update might have been interrupted.
In that case,
-# just wipe any leftovers and force the DB to be recreated.
-os.remove("{0}-journal".format(db_file))
-
-if os.path.exists(db_file):
-os.remove(db_file)
+cleanup_db_download(db_file, db_tmp_file)
# The NVD database changes once a day, so no need to update more frequently
# Allow the user to force-update
@@ -68,9 +60,60 @@ python do_fetch() {
pass
bb.utils.mkdirhier(db_dir)
+if os.path.exists(db_file):
+shutil.copy2(db_file, db_tmp_file)
+
+if update_db_file(db_tmp_file, d) == True:
+# Update downloaded correctly, can swap files
+shutil.move(db_tmp_file, db_file)
+else:
+# Update failed, do not modify the database
+bb.note("CVE database update failed")
+os.remove(db_tmp_file)
+}
+
+do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[file-checksums] = ""
+do_fetch[vardeps] = ""
+
+def cleanup_db_download(db_file, db_tmp_file):
+"""
+Cleanup the download space from possible failed downloads
+"""
+
+# Clean up the updates done on the main file
+# Remove it only if a journal file exists - it means a complete re-download
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_file))
+
+if os.path.exists(db_file):
+os.remove(db_file)
+
+# Clean-up the temporary file downloads, we can remove both journal
+# and the temporary database
+if os.path.exists("{0}-journal".format(db_tmp_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_tmp_file))
+
+if os.path.exists(db_tmp_file):
+os.remove(db_tmp_file)
+
+def update_db_file(db_tmp_file, d):
+"""
+Update the given database file
+"""
+import bb.utils, bb.progress
+from datetime import date
+import urllib, gzip, sqlite3
+
+YEAR_START = 2002
+cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
# Connect to database
-conn = sqlite3.connect(db_file)
+conn = sqlite3.connect(db_tmp_file)
initialize_db(conn)
with bb.progress.ProgressHandler(d) as ph,
open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f:
@@ -88,7 +131,7 @@ python do_fetch() {
except urllib.error.URLError as e:
cve_f.write('Warning: CVE db update error, Unable to fetch CVE
data.\n\n')
bb.warn("Failed to fetch CVE data (%s)" % e.reason)
-return
+return False
if response:
Re: [OE-core] [PATCH 2/2] cve-update-db-native: avoid partial updates
On Tue, Jan 3, 2023 at 10:30 AM Jose Quaresma
wrote:
>
>
> Marta Rybczynska escreveu no dia segunda,
> 2/01/2023 à(s) 16:38:
>
>>
>>
>> On Mon, Jan 2, 2023 at 2:14 PM Jose Quaresma
>> wrote:
>>
>>> Hi Marta,
>>>
>>> Marta Rybczynska escreveu no dia segunda,
>>> 2/01/2023 à(s) 07:03:
>>>
>>>> The database update has been done on the original file. In case of
>>>> network connection issues, temporary outage of the NVD server or
>>>> a similar situation, the function could exit with incomplete data
>>>> in the database. This patch solves the issue by performing the update
>>>> on a copy of the database. It replaces the main one only if the whole
>>>> update was successful.
>>>>
>>>> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
>>>>
>>>> Reported-by: Alberto Pianon
>>>> Signed-off-by: Marta Rybczynska
>>>> ---
>>>> .../recipes-core/meta/cve-update-db-native.bb | 81 +--
>>>> 1 file changed, 56 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
>>>> b/meta/recipes-core/meta/cve-update-db-native.bb
>>>> index 642fda5395..89804b9e5c 100644
>>>> --- a/meta/recipes-core/meta/cve-update-db-native.bb
>>>> +++ b/meta/recipes-core/meta/cve-update-db-native.bb
>>>> @@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
>>>> # Timeout for blocking socket operations, such as the connection
>>>> attempt.
>>>> CVE_SOCKET_TIMEOUT ?= "60"
>>>>
>>>> +CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
>>>> +
>>>> python () {
>>>> if not bb.data.inherits_class("cve-check", d):
>>>> raise bb.parse.SkipRecipe("Skip recipe when cve-check class is
>>>> not loaded.")
>>>> @@ -32,19 +34,15 @@ python do_fetch() {
>>>> """
>>>> import bb.utils
>>>> import bb.progress
>>>> -import sqlite3, urllib, urllib.parse, gzip
>>>> -from datetime import date
>>>> +import shutil
>>>>
>>>> bb.utils.export_proxies(d)
>>>>
>>>> -YEAR_START = 2002
>>>> -
>>>> db_file = d.getVar("CVE_CHECK_DB_FILE")
>>>> db_dir = os.path.dirname(db_file)
>>>> +db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
>>>>
>>>> -cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
>>>> -
>>>> -cleanup_db_download(db_file)
>>>> +cleanup_db_download(db_file, db_tmp_file)
>>>>
>>>> # The NVD database changes once a day, so no need to update more
>>>> frequently
>>>> # Allow the user to force-update
>>>> @@ -62,9 +60,55 @@ python do_fetch() {
>>>> pass
>>>>
>>>> bb.utils.mkdirhier(db_dir)
>>>> +if os.path.exists(db_file):
>>>> +shutil.copy2(db_file, db_tmp_file)
>>>> +
>>>> +if update_db_file(db_tmp_file, d) == True:
>>>> +# Update downloaded correctly, can swap files
>>>> +shutil.move(db_tmp_file, db_file)
>>>> +else:
>>>> +# Update failed, do not modify the database
>>>> +bb.note("CVE database update failed")
>>>> +os.remove(db_tmp_file)
>>>> +}
>>>> +
>>>> +do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
>>>> +do_fetch[file-checksums] = ""
>>>> +do_fetch[vardeps] = ""
>>>> +
>>>> +def cleanup_db_download(db_file, db_tmp_file):
>>>> +"""
>>>> +Cleanup the download space from possible failed downloads
>>>> +"""
>>>> +if os.path.exists("{0}-journal".format(db_file)):
>>>> +# If a journal is present the last update might have been
>>>> interrupted. In that case,
>>>> +# just wipe any leftovers and force the DB to be recreated.
>>>> +os.remove("{0}-journal".format(db_file))
>>>> +
>>>> +if os.path.exists(db_file):
>>>> +os.remove(db_file)
>>>> +
>>>&
[OE-core] NVD data format change and cve-check migration
Hello all, NVD (which we use for the cve-check database) has been working on the new format for some time. What I understand is that they plan to retire old API and all the feeds (like the one we use) by september 2023. Has anyone started working on migration of the cve-check to this new format? The current timeline: https://nvd.nist.gov/general/news/change-timeline Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175333): https://lists.openembedded.org/g/openembedded-core/message/175333 Mute This Topic: https://lists.openembedded.org/mt/96024052/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-db-native: avoid partial updates
On Mon, Jan 2, 2023 at 2:14 PM Jose Quaresma
wrote:
> Hi Marta,
>
> Marta Rybczynska escreveu no dia segunda,
> 2/01/2023 à(s) 07:03:
>
>> The database update has been done on the original file. In case of
>> network connection issues, temporary outage of the NVD server or
>> a similar situation, the function could exit with incomplete data
>> in the database. This patch solves the issue by performing the update
>> on a copy of the database. It replaces the main one only if the whole
>> update was successful.
>>
>> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
>>
>> Reported-by: Alberto Pianon
>> Signed-off-by: Marta Rybczynska
>> ---
>> .../recipes-core/meta/cve-update-db-native.bb | 81 +--
>> 1 file changed, 56 insertions(+), 25 deletions(-)
>>
>> diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
>> b/meta/recipes-core/meta/cve-update-db-native.bb
>> index 642fda5395..89804b9e5c 100644
>> --- a/meta/recipes-core/meta/cve-update-db-native.bb
>> +++ b/meta/recipes-core/meta/cve-update-db-native.bb
>> @@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
>> # Timeout for blocking socket operations, such as the connection attempt.
>> CVE_SOCKET_TIMEOUT ?= "60"
>>
>> +CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
>> +
>> python () {
>> if not bb.data.inherits_class("cve-check", d):
>> raise bb.parse.SkipRecipe("Skip recipe when cve-check class is
>> not loaded.")
>> @@ -32,19 +34,15 @@ python do_fetch() {
>> """
>> import bb.utils
>> import bb.progress
>> -import sqlite3, urllib, urllib.parse, gzip
>> -from datetime import date
>> +import shutil
>>
>> bb.utils.export_proxies(d)
>>
>> -YEAR_START = 2002
>> -
>> db_file = d.getVar("CVE_CHECK_DB_FILE")
>> db_dir = os.path.dirname(db_file)
>> +db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
>>
>> -cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
>> -
>> -cleanup_db_download(db_file)
>> +cleanup_db_download(db_file, db_tmp_file)
>>
>> # The NVD database changes once a day, so no need to update more
>> frequently
>> # Allow the user to force-update
>> @@ -62,9 +60,55 @@ python do_fetch() {
>> pass
>>
>> bb.utils.mkdirhier(db_dir)
>> +if os.path.exists(db_file):
>> +shutil.copy2(db_file, db_tmp_file)
>> +
>> +if update_db_file(db_tmp_file, d) == True:
>> +# Update downloaded correctly, can swap files
>> +shutil.move(db_tmp_file, db_file)
>> +else:
>> +# Update failed, do not modify the database
>> +bb.note("CVE database update failed")
>> +os.remove(db_tmp_file)
>> +}
>> +
>> +do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
>> +do_fetch[file-checksums] = ""
>> +do_fetch[vardeps] = ""
>> +
>> +def cleanup_db_download(db_file, db_tmp_file):
>> +"""
>> +Cleanup the download space from possible failed downloads
>> +"""
>> +if os.path.exists("{0}-journal".format(db_file)):
>> +# If a journal is present the last update might have been
>> interrupted. In that case,
>> +# just wipe any leftovers and force the DB to be recreated.
>> +os.remove("{0}-journal".format(db_file))
>> +
>> +if os.path.exists(db_file):
>> +os.remove(db_file)
>> +
>> +if os.path.exists("{0}-journal".format(db_tmp_file)):
>> +# If a journal is present the last update might have been
>> interrupted. In that case,
>> +# just wipe any leftovers and force the DB to be recreated.
>> +os.remove("{0}-journal".format(db_tmp_file))
>> +
>> +if os.path.exists(db_tmp_file):
>> +os.remove(db_tmp_file)
>> +
>>
>
> It seems to me that this function is a duplication of the old version with
> an extra argument.
> So I think that using the old function version and call it with the proper
> argument does the same:
>
> cleanup_db_download(db_file)
> cleanup_db_download(db_tmp_file)
>
>
Hi Jose,
Thanks for looking into that. The function is not a total duplicate: the
difference is that
the it always removes the db_tmp_file, not only if the journal file exists
(Python code
formatting!).
I was hesitating on this part a bit, because with the old path could be
taken only in some
specific situations: at the code update and if you share the DL_DIR and
some of the builds
use the old code, some the new version. I think we should keep both for now
for safety.
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175322):
https://lists.openembedded.org/g/openembedded-core/message/175322
Mute This Topic: https://lists.openembedded.org/mt/96002809/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] cve-update-db-native: avoid partial updates
The database update has been done on the original file. In case of
network connection issues, temporary outage of the NVD server or
a similar situation, the function could exit with incomplete data
in the database. This patch solves the issue by performing the update
on a copy of the database. It replaces the main one only if the whole
update was successful.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
Reported-by: Alberto Pianon
Signed-off-by: Marta Rybczynska
---
.../recipes-core/meta/cve-update-db-native.bb | 81 +--
1 file changed, 56 insertions(+), 25 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 642fda5395..89804b9e5c 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
# Timeout for blocking socket operations, such as the connection attempt.
CVE_SOCKET_TIMEOUT ?= "60"
+CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
+
python () {
if not bb.data.inherits_class("cve-check", d):
raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not
loaded.")
@@ -32,19 +34,15 @@ python do_fetch() {
"""
import bb.utils
import bb.progress
-import sqlite3, urllib, urllib.parse, gzip
-from datetime import date
+import shutil
bb.utils.export_proxies(d)
-YEAR_START = 2002
-
db_file = d.getVar("CVE_CHECK_DB_FILE")
db_dir = os.path.dirname(db_file)
+db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
-cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
-
-cleanup_db_download(db_file)
+cleanup_db_download(db_file, db_tmp_file)
# The NVD database changes once a day, so no need to update more frequently
# Allow the user to force-update
@@ -62,9 +60,55 @@ python do_fetch() {
pass
bb.utils.mkdirhier(db_dir)
+if os.path.exists(db_file):
+shutil.copy2(db_file, db_tmp_file)
+
+if update_db_file(db_tmp_file, d) == True:
+# Update downloaded correctly, can swap files
+shutil.move(db_tmp_file, db_file)
+else:
+# Update failed, do not modify the database
+bb.note("CVE database update failed")
+os.remove(db_tmp_file)
+}
+
+do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[file-checksums] = ""
+do_fetch[vardeps] = ""
+
+def cleanup_db_download(db_file, db_tmp_file):
+"""
+Cleanup the download space from possible failed downloads
+"""
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_file))
+
+if os.path.exists(db_file):
+os.remove(db_file)
+
+if os.path.exists("{0}-journal".format(db_tmp_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_tmp_file))
+
+if os.path.exists(db_tmp_file):
+os.remove(db_tmp_file)
+
+def update_db_file(db_tmp_file, d):
+"""
+Update the given database file
+"""
+import bb.utils, bb.progress
+from datetime import date
+import urllib, gzip, sqlite3
+
+YEAR_START = 2002
+cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
# Connect to database
-conn = sqlite3.connect(db_file)
+conn = sqlite3.connect(db_tmp_file)
initialize_db(conn)
with bb.progress.ProgressHandler(d) as ph,
open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f:
@@ -82,7 +126,7 @@ python do_fetch() {
except urllib.error.URLError as e:
cve_f.write('Warning: CVE db update error, Unable to fetch CVE
data.\n\n')
bb.warn("Failed to fetch CVE data (%s)" % e.reason)
-return
+return False
if response:
for l in response.read().decode("utf-8").splitlines():
@@ -92,7 +136,7 @@ python do_fetch() {
break
else:
bb.warn("Cannot parse CVE metadata, update failed")
-return
+return False
# Compare with current db last modified date
cursor = conn.execute("select DATE from META where YEAR = ?",
(year,))
@@ -113,7 +157,7 @@ python do_fetch() {
except urllib.error.URLError as e:
[OE-core] [PATCH 1/2] cve-update-db-native: move download cleanup to a function
Move cleanup of the database after a failed download to a separate
function. This will be useful when we have more actions to do in
that situation.
Signed-off-by: Marta Rybczynska
---
meta/recipes-core/meta/cve-update-db-native.bb | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 9b9dbbd75f..642fda5395 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -44,13 +44,7 @@ python do_fetch() {
cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
-if os.path.exists("{0}-journal".format(db_file)):
-# If a journal is present the last update might have been interrupted.
In that case,
-# just wipe any leftovers and force the DB to be recreated.
-os.remove("{0}-journal".format(db_file))
-
-if os.path.exists(db_file):
-os.remove(db_file)
+cleanup_db_download(db_file)
# The NVD database changes once a day, so no need to update more frequently
# Allow the user to force-update
@@ -134,6 +128,15 @@ do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
do_fetch[file-checksums] = ""
do_fetch[vardeps] = ""
+def cleanup_db_download(db_file):
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_file))
+
+if os.path.exists(db_file):
+os.remove(db_file)
+
def initialize_db(conn):
with conn:
c = conn.cursor()
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175313):
https://lists.openembedded.org/g/openembedded-core/message/175313
Mute This Topic: https://lists.openembedded.org/mt/96002806/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [kirkstone][OE-core][PATCH] efibootmgr: update compilation with musl
On Wed, Dec 14, 2022 at 5:08 PM Steve Sakoman wrote:
> On Wed, Dec 14, 2022 at 4:29 AM Marta Rybczynska
> wrote:
> >
> > Since the commit 005b6aba89eaf1b79fdd7565dd028fdd9bbfcc7d
> > (efivar: add musl libc compatibility) efibootmgr compiles with
> > musl too. Update the variable to take that into account.
> >
> > Signed-off-by: Marta Rybczynska
> > ---
> > meta/recipes-bsp/efibootmgr/efibootmgr_17.bb | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> > index 11d8b9061d..be6571b3fa 100644
> > --- a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> > +++ b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> > @@ -34,6 +34,4 @@ do_install () {
> > }
> >
> > CLEANBROKEN = "1"
> > -# https://github.com/rhboot/efivar/issues/202
> > -COMPATIBLE_HOST:libc-musl = 'null'
>
> I see that master also has the above -- should it also be removed in
> master? If so, resubmit for master and I will backport to kirkstone.
>
>
>
Al three branches finished compilation just fine, so all three are
submitted. You can pick it up the moment
it hits master.
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174574):
https://lists.openembedded.org/g/openembedded-core/message/174574
Mute This Topic: https://lists.openembedded.org/mt/95667399/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][langdale][PATCH] efibootmgr: update compilation with musl
Since the commit 005b6aba89eaf1b79fdd7565dd028fdd9bbfcc7d
(efivar: add musl libc compatibility) efibootmgr compiles with
musl too. Update the variable to take that into account.
Signed-off-by: Marta Rybczynska
---
meta/recipes-bsp/efibootmgr/efibootmgr_18.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
b/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
index cbcaac1e97..fbd2f5dbc8 100644
--- a/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
+++ b/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
@@ -30,6 +30,3 @@ do_install () {
}
CLEANBROKEN = "1"
-# https://github.com/rhboot/efivar/issues/202
-COMPATIBLE_HOST:libc-musl = 'null'
-
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174559):
https://lists.openembedded.org/g/openembedded-core/message/174559
Mute This Topic: https://lists.openembedded.org/mt/95674323/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] efibootmgr: update compilation with musl
Since the commit 005b6aba89eaf1b79fdd7565dd028fdd9bbfcc7d
(efivar: add musl libc compatibility) efibootmgr compiles with
musl too. Update the variable to take that into account.
Signed-off-by: Marta Rybczynska
---
meta/recipes-bsp/efibootmgr/efibootmgr_18.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
b/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
index cbcaac1e97..fbd2f5dbc8 100644
--- a/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
+++ b/meta/recipes-bsp/efibootmgr/efibootmgr_18.bb
@@ -30,6 +30,3 @@ do_install () {
}
CLEANBROKEN = "1"
-# https://github.com/rhboot/efivar/issues/202
-COMPATIBLE_HOST:libc-musl = 'null'
-
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174558):
https://lists.openembedded.org/g/openembedded-core/message/174558
Mute This Topic: https://lists.openembedded.org/mt/95673380/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [kirkstone][OE-core][PATCH] efibootmgr: update compilation with musl
On Wed, Dec 14, 2022 at 3:29 PM Marta Rybczynska via lists.openembedded.org wrote: > Since the commit 005b6aba89eaf1b79fdd7565dd028fdd9bbfcc7d > (efivar: add musl libc compatibility) efibootmgr compiles with > musl too. Update the variable to take that into account. > > Langdale and master versions will follow in a moment, they are building now. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174556): https://lists.openembedded.org/g/openembedded-core/message/174556 Mute This Topic: https://lists.openembedded.org/mt/95667399/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[kirkstone][OE-core][PATCH] efibootmgr: update compilation with musl
Since the commit 005b6aba89eaf1b79fdd7565dd028fdd9bbfcc7d
(efivar: add musl libc compatibility) efibootmgr compiles with
musl too. Update the variable to take that into account.
Signed-off-by: Marta Rybczynska
---
meta/recipes-bsp/efibootmgr/efibootmgr_17.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
index 11d8b9061d..be6571b3fa 100644
--- a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
+++ b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
@@ -34,6 +34,4 @@ do_install () {
}
CLEANBROKEN = "1"
-# https://github.com/rhboot/efivar/issues/202
-COMPATIBLE_HOST:libc-musl = 'null'
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174555):
https://lists.openembedded.org/g/openembedded-core/message/174555
Mute This Topic: https://lists.openembedded.org/mt/95667399/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone] core-image-weston doesn't build
$ bitbake weston Loading cache: 100% |###| Time: 0:00:00 Loaded 1640 entries from dependency cache. ERROR: Nothing PROVIDES 'weston' weston was skipped: missing required distro features 'wayland opengl' (not in DISTRO_FEATURES) Summary: There was 1 ERROR message, returning a non-zero exit code. I can add distro-features et al, just wondering if this image is expected to build by default with oe-core? Regards, Marta On Thu, Oct 13, 2022 at 10:15 AM Alexander Kanavin wrote: > > What happens when you run 'bitbake weston'? > > Alex > > On Thu, 13 Oct 2022 at 10:10, Marta Rybczynska wrote: > > > > > > > > On Thu, 13 Oct 2022, 17:00 Alexandre Belloni, > > wrote: > >> > >> On 13/10/2022 09:52:44+0200, Marta Rybczynska wrote: > >> > Hello all, > >> > I'm trying to build the core-image-weston in kirkstone to look into > >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14926 > >> > > >> > It turns out that the image does not build (oe-core > >> > e728d0965d6fda8ac54e065ca7bf7eb9da9a8170 with bitbake > >> > 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e). I'm getting: > >> > > >> > $ bitbake core-image-weston > >> > Loading cache: 100% > >> > |###| > >> > Time: 0:00:00 > >> > Loaded 1640 entries from dependency cache. > >> > NOTE: Resolving any missing task queue dependencies > >> > ERROR: Nothing RPROVIDES 'weston-xwayland' (but > >> > /oe-standalone/oe-core/meta/recipes-graphics/images/core-image-weston.bb > >> > RDEPENDS on > >> > or otherwise requires it) > >> > NOTE: Runtime target 'weston-xwayland' is unbuildable, removing... > >> > Missing or unbuildable dependency chain was: ['weston-xwayland'] > >> > ERROR: Required build target 'core-image-weston' has no buildable > >> > providers. > >> > Missing or unbuildable dependency chain was: ['core-image-weston', > >> > 'weston-xwayland'] > >> > > >> > Summary: There were 2 ERROR messages, returning a non-zero exit code. > >> > > >> > I can't find this one in bugzilla. Is it a known issue? > >> > > >> > >> Did you remove x11 from your DISTRO_FEATURES? > > > > > > No. This is a fresh clone. The only changes I have are in local.conf: > > DL_DIR and parallel build options. That's why I'm surprised. > > > > Regards > > Marta > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171696): https://lists.openembedded.org/g/openembedded-core/message/171696 Mute This Topic: https://lists.openembedded.org/mt/94299411/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone] core-image-weston doesn't build
On Thu, 13 Oct 2022, 17:00 Alexandre Belloni, wrote: > On 13/10/2022 09:52:44+0200, Marta Rybczynska wrote: > > Hello all, > > I'm trying to build the core-image-weston in kirkstone to look into > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14926 > > > > It turns out that the image does not build (oe-core > > e728d0965d6fda8ac54e065ca7bf7eb9da9a8170 with bitbake > > 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e). I'm getting: > > > > $ bitbake core-image-weston > > Loading cache: 100% > > > |###| > > Time: 0:00:00 > > Loaded 1640 entries from dependency cache. > > NOTE: Resolving any missing task queue dependencies > > ERROR: Nothing RPROVIDES 'weston-xwayland' (but > > /oe-standalone/oe-core/meta/recipes-graphics/images/core-image-weston.bb > > RDEPENDS on > > or otherwise requires it) > > NOTE: Runtime target 'weston-xwayland' is unbuildable, removing... > > Missing or unbuildable dependency chain was: ['weston-xwayland'] > > ERROR: Required build target 'core-image-weston' has no buildable > providers. > > Missing or unbuildable dependency chain was: ['core-image-weston', > > 'weston-xwayland'] > > > > Summary: There were 2 ERROR messages, returning a non-zero exit code. > > > > I can't find this one in bugzilla. Is it a known issue? > > > > Did you remove x11 from your DISTRO_FEATURES? > No. This is a fresh clone. The only changes I have are in local.conf: DL_DIR and parallel build options. That's why I'm surprised. Regards Marta > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171687): https://lists.openembedded.org/g/openembedded-core/message/171687 Mute This Topic: https://lists.openembedded.org/mt/94299411/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone] core-image-weston doesn't build
Hello all, I'm trying to build the core-image-weston in kirkstone to look into https://bugzilla.yoctoproject.org/show_bug.cgi?id=14926 It turns out that the image does not build (oe-core e728d0965d6fda8ac54e065ca7bf7eb9da9a8170 with bitbake 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e). I'm getting: $ bitbake core-image-weston Loading cache: 100% |###| Time: 0:00:00 Loaded 1640 entries from dependency cache. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'weston-xwayland' (but /oe-standalone/oe-core/meta/recipes-graphics/images/core-image-weston.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'weston-xwayland' is unbuildable, removing... Missing or unbuildable dependency chain was: ['weston-xwayland'] ERROR: Required build target 'core-image-weston' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-weston', 'weston-xwayland'] Summary: There were 2 ERROR messages, returning a non-zero exit code. I can't find this one in bugzilla. Is it a known issue? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171685): https://lists.openembedded.org/g/openembedded-core/message/171685 Mute This Topic: https://lists.openembedded.org/mt/94299411/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] severe issue in CVE checker
Reported as https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929 On Wed, Oct 12, 2022 at 6:29 PM Ross Burton wrote: > > On 12 Oct 2022, at 08:25, Alberto Pianon via lists.openembedded.org > wrote: > > > > It iterates over NIST CVE db years, but if some year fail to download, it > > goes on anyway, and it still merges the successful downloads into > > nvdcve_1.1.db, without returning error. > > > > IMHO this is a severe issue because it may silently lead to false negatives > > in the CVE check. If some downloads fail due to timeouts or other > > connection problems, cve-check should retry a number of times, and if any > > download still fails, cve-update-db-native do_fecth should fail, and it > > turn all do_cve_check tasks should fail, since doing a CVE check against a > > corrupted/incomplete CVE database is clearly useless > > Yes, that’s a bug. > > Please do file a bug (bugzilla.yoctoproject.org), and ideally send a patch if > you can. > > Ross > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171681): https://lists.openembedded.org/g/openembedded-core/message/171681 Mute This Topic: https://lists.openembedded.org/mt/94276393/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] severe issue in CVE checker
Mikko et al, I think that we all agree here that we need to fix that database corruption. BTW The Oniro team has worked to fix many issues from the list you mention, including frequent communication with NVD. Alberto and team have been stressing the tool more than most people before, I think. This is a good thing. And that they find bugs in the process... I agree that the cve-check does not give perfect security (after all, not all security issues have CVEs, and there is a delay between the CVE creation and the NVD update). Using it is the best recommendation we have for the users so it is in interest of all of us to make sure the check is working reliably. We don't want unnoticed security issues in our appliances, don't we? :) So, let's concentrate on "how"/"who" in the process of fixing this issue... Kind regards, Marta On Wed, Oct 12, 2022 at 12:03 PM Mikko Rapeli wrote: > > Hi, > > I did not mean that yocto CVE checker is useless, or that bugs like > this should not be fixed. Using it is part of the best practice > processes for making secure products with yocto (even if it's currently > not documented as such). > > But we should also document that the CVE checker makes a LOT of > assumptions which are frequently broken in real life. poky tries to work well > with CVE checker but many other layers and recipes may not work at all. > > Few reasons are: > > * recipe name may not match to a CPE product name in the NVD database, >and CVE_PRODUCT may not be set > > * recipe versions PV may not be compatible with upstream version >numbers and hance the version range checks may fail > > * data in NVD is frequently wrong about the version ranges of CVEs > > And there are more corner cases. All these fail silently. > > Now you found a problem with the NVD download scripting which I think > needs to be fixed. But even if it works, developers who need to run > security checks on real products need to do more than just rely on > CVE check output. > > Cheers, > > -Mikko > > On Wed, Oct 12, 2022 at 11:51:28AM +0200, Carlo Piana wrote: > > [sent from the wrong account, resent, sorry for the noise] > > > > - Messaggio originale ----- > > > Da: "Mikko Rapeli" > > > A: "Marta Rybczynska" > > > Cc: "Alexander Kanavin" , "Alberto Pianon" > > > , "OE-core" > > > , "marta rybczynska" > > > , "Richard Purdie" > > > , "Carlo Piana" > > > Inviato: Mercoledì, 12 ottobre 2022 10:04:07 > > > Oggetto: Re: [OE-core] severe issue in CVE checker > > > > > Hi, > > > > > > Can the downloads be turned into normal do_fetch() SRC_URI downloads > > > including > > > caches in yocto infrastructure? > > > > > > There are many issues around CVE checking that it's really > > > a process where a lot of details and uncertainties just need to be > > > accepted. It's far from a perfect and users just need to accept this. > > > > > > > > > > [...] > > > > I beg to (strongly, if I may) differ. > > > > CVE is broken? This is no excuse of course to ignore a known insecurity. > > > > Is it better to include a process that, when fails, the fail goes > > unnoticed, than nothing? No, "nothing" is better than flawed here, speaking > > of security, since a false sense of security is worse than insecurity > > itself. > > > > If we put a CVE checker that just throws in a contradictory message (a > > warning and eventually a "success" one) and then silently moves on without > > any fuss, we leave users in a state of false belief that they have > > completed at least the CVE checks -- however insufficient this may be -- > > but in reality it's a test that never fails because the database is empty > > or outdated. I agree that for developers CVE checking, compliance, software > > component inventory are a PITA, but it's way more a PITA when an attacker > > exploits an unpatched known insecurity kept out in the wild, or when a > > copyright troll comes after you demanding (many!) millions in damages (I > > can't disclose who has received it, but I have seen it in real life), > > because you failed to notice that a GPL component went into a > > mass-distribution device. > > > > Once the function is advertised, the expected behaviour for a thing of that > > importance must be to visibly flag the issue and **stand in the way** until > > you acknowledge it, so that the warning cannot be missed. It is up to the > > duly informed
Re: [OE-core] severe issue in CVE checker
I'll be looking into how to fix it. My current idea is to make the download a transaction, so do not update the database until we're sure the download is complete. Plus a warning that we have had an issue, I think. In a next step we can retry a number of times. Regards Marta On Wed, 12 Oct 2022, 16:50 Alexander Kanavin, wrote: > Thanks for the information, can you send a patch? > > Alex > > On Wed, 12 Oct 2022 at 09:25, Alberto Pianon wrote: > > > > All, Marta, Richard, > > > > while implementing stats aggregation for CVE metadata in the Oniro > > project, I encountered a severe issue in Yocto's CVE checker, apparently > > due to this: > > > https://git.yoctoproject.org/poky/tree/meta/recipes-core/meta/cve-update-db-native.bb#n81 > > > > It appears that when cve-update-db-native fails to fetch some years of > > NIST CVE db, it just issues a warning but goes on anyway. > > > > The result is that in some builds, randomly (depending on NIST webserver > > timeouts or other connection problems), CVE db is not complete, so the > > CVE check returns false negatives (i.e. no vulnerabilities found in some > > components even if such vulnerabilities do exist) > > > > I ran into such problem because in Oniro we need aggregate data from > > different builds for a large target matrix; I added a check to check > > that CVE metadata for each component are the same in all builds, and it > > failed, so I tried to figure out the cause and I found this: > > > > - in a build where cve-check found a vulnerability for acl: > > $ sqlite3 build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db > > sqlite> SELECT DISTINCT ID FROM PRODUCTS WHERE PRODUCT IS "acl"; > > CVE-2009-4411 > > sqlite> > > > > - in another build where cve-check did not found any vulnerability for > > the very same version of acl: > > $ sqlite3 build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db > > sqlite> SELECT DISTINCT ID FROM PRODUCTS WHERE PRODUCT IS "acl"; > > sqlite> > > > > so I listed both CVE db files in those two builds and this is what I > > got: > > > > $ ls -ll build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db > > build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db > > -rw-r--r-- 1 ubuntu ubuntu 215093248 Oct 11 10:56 > > build-linux-clang-qemuarm-efi/tmp/CVE_CHECK/nvdcve_1.1.db > > -rw-r--r-- 1 ubuntu ubuntu 28672 Oct 11 10:00 > > build-linux-clang-qemux86/tmp/CVE_CHECK/nvdcve_1.1.db > > > > The two CVE db files were fetched just about 1h apart, but the second > > file is apparently incomplete. > > > > I checked the log for the second build, and I found this: > > > > WARNING: cve-update-db-native-1.0-r0 do_fetch: Failed to fetch CVE > > data ([Errno 99] Cannot assign requested address) > > NOTE: recipe cve-update-db-native-1.0-r0: task do_fetch: Succeeded > > > > Fetch fails, but do_fetch task succeeds. > > > > So I looked into the recipe's code, and I found this: > > > https://git.yoctoproject.org/poky/tree/meta/recipes-core/meta/cve-update-db-native.bb#n81 > > > > It iterates over NIST CVE db years, but if some year fail to download, > > it goes on anyway, and it still merges the successful downloads into > > nvdcve_1.1.db, without returning error. > > > > IMHO this is a severe issue because it may silently lead to false > > negatives in the CVE check. If some downloads fail due to timeouts or > > other connection problems, cve-check should retry a number of times, and > > if any download still fails, cve-update-db-native do_fecth should fail, > > and it turn all do_cve_check tasks should fail, since doing a CVE check > > against a corrupted/incomplete CVE database is clearly useless > > > > Regards, > > > > Alberto > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171658): https://lists.openembedded.org/g/openembedded-core/message/171658 Mute This Topic: https://lists.openembedded.org/mt/94276393/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Adding more information to the SBOM
Dear all, (cross-posting to oe-core and *-architecture) In the last months, we have worked in Oniro on using the create-spdx class for both IP compliance and security. During this work, Alberto Pianon has found that some information is missing from the SBOM and it does not contain enough for Software Composition Analysis. The main missing point is the relation between the actual upstream sources and the final binaries (create-spdx uses composite sources). Alberto has worked on how to obtain the missing data and now has a POC. This POC provides full source-to-binary tracking of Yocto builds through a couple of scripts (intended to be transformed into a new bbclass at a later stage). The goal is to add the missing pieces of information in order to get a "real" SBOM from Yocto, which should, at a minimum: - carefully describe what is found in a final image (i.e. binary files and their dependencies), since that is what is actually distributed and goes into the final product; - describe how such binary files have been generated and where they come from (i.e. upstream sources, including patches and other stuff added from meta-layers); provenance is important for a number of reasons related to IP Compliance and security. The aim is to become able to: - map binaries to their corresponding upstream source packages (and not to the "internal" source packages created by recipes by combining multiple upstream sources and patches) - map binaries to the source files that have been actually used to build them - which usually are a small subset of the whole source package With respect to IP compliance, this would allow to, among other things: - get the real license text for each binary file, by getting the license of the specific source files it has been generated from (provided by Fossology, for instance), - and not the main license stated in the corresponding recipe (which may be as confusing as GPL-2.0-or-later & LGPL-2.1-or-later & BSD-3-Clause & BSD-4-Clause, or even worse) - automatically check license incompatibilities at the binary file level. Other possible interesting things could be done also on the security side. This work intends to add a way to provide additional data that can be used by create-spdx, not to replace create-spdx in any way. The sources with a long README are available at https://gitlab.eclipse.org/eclipse/oniro-compliancetoolchain/toolchain/tinfoilhat/-/tree/srctracker/srctracker What do you think of this work? Would it be of interest to integrate into YP at some point? Shall we discuss this? Marta and Alberto -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170659): https://lists.openembedded.org/g/openembedded-core/message/170659 Mute This Topic: https://lists.openembedded.org/mt/93678488/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] CVE raffle: collision avoidance
On Mon, Sep 12, 2022 at 9:16 PM Steve Sakoman wrote: > > On Mon, Sep 12, 2022 at 8:57 AM Martin Jansa wrote: > > > > You mean this list? > > https://lists.yoctoproject.org/g/yocto-security/message/655 > > Yes, I assumed everyone was aware of the weekly CVE list! Did you > have something else in mind? Sorry for the confusion. I meant that exact list and suggested to use it as a reservation list without manually looking into this thread and verifying with the three different CVE emails. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170545): https://lists.openembedded.org/g/openembedded-core/message/170545 Mute This Topic: https://lists.openembedded.org/mt/93637108/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] CVE raffle: collision avoidance
On Mon, 12 Sept 2022, 17:55 Steve Sakoman, wrote: > Reply to this thread noting which CVE you plan to work on. Please > don't claim one unless you really intend to follow through! > > Hello Steve, What about sending the list of pending CVEs (from the existing dunfell/kirkstone/master lists) for easier tracking? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170540): https://lists.openembedded.org/g/openembedded-core/message/170540 Mute This Topic: https://lists.openembedded.org/mt/93637108/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] classes: cve-check: Get shared database lock
On Fri, Sep 2, 2022 at 9:09 AM Marta Rybczynska via
lists.openembedded.org
wrote:
>
> On Tue, Aug 30, 2022 at 5:59 PM Joshua Watt wrote:
> >
> > The CVE check database needs to have a shared lock acquired on it before
> > it is accessed. This to prevent cve-update-db-native from deleting the
> > database file out from underneath it.
> >
> > [YOCTO #14899]
> >
> > Signed-off-by: Joshua Watt
> > +cve_data = get_cve_info(d, patched + unpatched + ignored)
> > +cve_write_data(d, patched, unpatched, ignored, cve_data,
> > status)
> > +else:
> > +bb.note("No CVE database found, skipping CVE check")
> >
>
> With this commit in kirkstone-nut, we're getting an error with
> meta-zephyr builds:
>
> RROR: zephyr-philosophers-3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0
> do_cve_check: Error executing a python function in exec_func_python()
> autogenerated:
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:do_cve_check(d)
> 0003:
> File: '/tmp/workspace.4jc1Y12y3W/oe-core/meta/classes/cve-check.bbclass',
> lineno: 142, function: do_cve_check
> 0138: Check recipe for patched and unpatched CVEs
> 0139: """
> 0140: from oe.cve_check import get_patched_cves
> 0141:
> *** 0142: with bb.utils.fileslocked([d.getVar("CVE_CHECK_DB_FILE_LOCK")],
> shared=True):
> 0143: if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")):
> 0144: try:
> 0145: patched_cves = get_patched_cves(d)
> 0146: except FileNotFoundError:
> File: '/usr/lib/python3.8/contextlib.py', lineno: 240, function: helper
> 0236:
> 0237: """
> 0238: @wraps(func)
> 0239: def helper(*args, **kwds):
> *** 0240: return _GeneratorContextManager(func, args, kwds)
> 0241: return helper
> 0242:
> 0243:
> 0244:def asynccontextmanager(func):
> File: '/usr/lib/python3.8/contextlib.py', lineno: 83, function: __init__
> 0079:class _GeneratorContextManagerBase:
> 0080: """Shared functionality for @contextmanager and @asynccontextmanager."""
> 0081:
> 0082: def __init__(self, func, args, kwds):
> *** 0083: self.gen = func(*args, **kwds)
> 0084: self.func, self.args, self.kwds = func, args, kwds
> 0085: # Issue 19330: ensure context manager instances have good docstrings
> 0086: doc = getattr(func, "__doc__", None)
> 0087: if doc is None:
> Exception: TypeError: fileslocked() got an unexpected keyword argument
> 'shared'
> ERROR: Logfile of failure stored in:
> /tmp/workspace.4jc1Y12y3W/build/tmp-newlib/work/i586-yocto-elf/zephyr-philosophers/3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0/temp/log.do_cve_check.433603
> NOTE: recipe zephyr-philosophers-3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0:
> task do_cve_check: Failed
> ERROR: Task
> (/tmp/workspace.4jc1Y12y3W/oe-core/../meta-zephyr/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb:do_cve_check)
> failed with exit code '1'
>
This is a mismatch with bitbake, because one commit hasn't reached 2.0.
Steve, should I be using
https://git.openembedded.org/bitbake-contrib/log/?h=stable/2.0-nut for
testing?
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170239):
https://lists.openembedded.org/g/openembedded-core/message/170239
Mute This Topic: https://lists.openembedded.org/mt/93352038/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] classes: cve-check: Get shared database lock
On Tue, Aug 30, 2022 at 5:59 PM Joshua Watt wrote:
>
> The CVE check database needs to have a shared lock acquired on it before
> it is accessed. This to prevent cve-update-db-native from deleting the
> database file out from underneath it.
>
> [YOCTO #14899]
>
> Signed-off-by: Joshua Watt
> +cve_data = get_cve_info(d, patched + unpatched + ignored)
> +cve_write_data(d, patched, unpatched, ignored, cve_data,
> status)
> +else:
> +bb.note("No CVE database found, skipping CVE check")
>
With this commit in kirkstone-nut, we're getting an error with
meta-zephyr builds:
RROR: zephyr-philosophers-3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0
do_cve_check: Error executing a python function in exec_func_python()
autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function:
0001:
*** 0002:do_cve_check(d)
0003:
File: '/tmp/workspace.4jc1Y12y3W/oe-core/meta/classes/cve-check.bbclass',
lineno: 142, function: do_cve_check
0138: Check recipe for patched and unpatched CVEs
0139: """
0140: from oe.cve_check import get_patched_cves
0141:
*** 0142: with bb.utils.fileslocked([d.getVar("CVE_CHECK_DB_FILE_LOCK")],
shared=True):
0143: if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")):
0144: try:
0145: patched_cves = get_patched_cves(d)
0146: except FileNotFoundError:
File: '/usr/lib/python3.8/contextlib.py', lineno: 240, function: helper
0236:
0237: """
0238: @wraps(func)
0239: def helper(*args, **kwds):
*** 0240: return _GeneratorContextManager(func, args, kwds)
0241: return helper
0242:
0243:
0244:def asynccontextmanager(func):
File: '/usr/lib/python3.8/contextlib.py', lineno: 83, function: __init__
0079:class _GeneratorContextManagerBase:
0080: """Shared functionality for @contextmanager and @asynccontextmanager."""
0081:
0082: def __init__(self, func, args, kwds):
*** 0083: self.gen = func(*args, **kwds)
0084: self.func, self.args, self.kwds = func, args, kwds
0085: # Issue 19330: ensure context manager instances have good docstrings
0086: doc = getattr(func, "__doc__", None)
0087: if doc is None:
Exception: TypeError: fileslocked() got an unexpected keyword argument 'shared'
ERROR: Logfile of failure stored in:
/tmp/workspace.4jc1Y12y3W/build/tmp-newlib/work/i586-yocto-elf/zephyr-philosophers/3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0/temp/log.do_cve_check.433603
NOTE: recipe zephyr-philosophers-3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0:
task do_cve_check: Failed
ERROR: Task
(/tmp/workspace.4jc1Y12y3W/oe-core/../meta-zephyr/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb:do_cve_check)
failed with exit code '1'
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170235):
https://lists.openembedded.org/g/openembedded-core/message/170235
Mute This Topic: https://lists.openembedded.org/mt/93352038/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone] [PATCH] sqlite: Increase the size of loop variables in the printf() implementation to avoid harmless compiler warnings.
On Thu, Aug 25, 2022 at 9:25 AM ghassaneben wrote: > From: ghassaneben > > Increase the size of loop variables in the printf() implementation to > avoid integer overflow on multi-gigabyte string arguments. CVE-2022-35737. > This bug fix refers to: CVE-2022-35737 and it's a backport of a fix added > in sqlite 3.39.2 (2022-07-21). > Original commit: https://www.sqlite.org/src/info/aab790a16e1bdff7. > > Steve, I'm adding it to your watch list. This is a CVE fix contrary to the "harmless warnings" one of the commit messages is telling us. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169837): https://lists.openembedded.org/g/openembedded-core/message/169837 Mute This Topic: https://lists.openembedded.org/mt/93243836/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] Yocto Project Status 02 August 2022 (WW31)
On Tue, Aug 2, 2022 at 4:49 PM Neal Caidin wrote: > > Current Dev Position: YP 4.1 M3 > > Next Deadline: 22nd August 2022 YP 4.1 M3 Build > > > Next Team Meetings: > > Bug Triage meeting Thursday August 4th 7:30 am PDT > (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09) > > Weekly Project Engineering Sync Tuesday August 2nd at 8 am PDT > (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09) > > Twitch - See https://www.twitch.tv/theyoctojester > > > Key Status/Updates: > > YP 4.1 M2 was released > > YP 3.1.18 passed QA and is due to be released > > The debug file mapping issues have moved slightly further forward thanks to > some help from Ross but are stalling due to insufficient developer time > available to resolve the issues. > > Some rust toolchain improvements did merge, including an automated rust > toolchain test. The bulk of the rework is stalled on a handful of remaining > issues, particularly a couple of reproducibility problems but also a mips n32 > toolchain issue. > > We have one open CVE on master against qemu, help to backport that fix would > be very welcome to keep the numbers down. CVEs in kirkstone (LTS) > significantly reduced. Do you mean CVE-2022-35414? Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168795): https://lists.openembedded.org/g/openembedded-core/message/168795 Mute This Topic: https://lists.openembedded.org/mt/92771754/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4
On Tue, Aug 2, 2022 at 4:57 PM Steve Sakoman wrote:
>
> On Tue, Aug 2, 2022 at 4:37 AM Steve Sakoman via
> lists.openembedded.org
> wrote:
> >
> > On Mon, Aug 1, 2022 at 7:56 PM Marta Rybczynska
> > wrote:
> > >
> > > On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman wrote:
> > > >
> > > > From: Alexander Kanavin
> > > >
> > > > Security update
> > > >
> > >
> > > With this update we're getting:
> > >
> > > Parsing recipes...WARNING:
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > Exception during build_dependencies for AUTOREV
> > > WARNING:
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > Error during finalise of
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > ERROR: ExpansionError during parsing
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > Traceback (most recent call last):
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > 249, in Git.urldata_init(ud= > > 0x7fc0cb054970>, d= > > 0x7fc0cafbd0d0>):
> > > > ud.setup_revisions(d)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1347, in FetchData.setup_revisions(d= > > object at 0x7fc0cafbd0d0>):
> > > for name in self.names:
> > > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1212, in srcrev_internal_helper(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > if srcrev == "AUTOINC":
> > > > srcrev = ud.method.latest_revision(ud, d, name)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1624, in Git.latest_revision(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > except KeyError:
> > > > revs[key] = rev = self._latest_revision(ud, d, name)
> > > return rev
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > 752, in Git._latest_revision(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > return sha1
> > > > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git
> > > > repository in git ls-remote output for %s" % \
> > > (ud.unresolvedrev[name], ud.host+ud.path))
> > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> > > FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> > > upstream git repository in git ls-remote output for
> > > github.com/JeffyCN/xorg-xserver
> >
> > Is there a bbappend to xserver-xorg somewhere in your layers?
> >
> > The recipe in core is building from a tarball fetched from
> > https://www.x.org/releases/
> >
> > It appears that a bbappend is changing this to look in
> > github.com/JeffyCN/xorg-xserver, which doesn't have 21.1.4
> >
> > So my best guess is that the issue is with a bbappend in some other
> > layer, not with this patch in oe-core.
>
> I'm going to guess you've included meta-rockchip in your build which
> does include this bbappend:
>
> https://github.com/JeffyCN/meta-rockchip/blob/master/recipes-graphics/xorg-xserver/xserver-xorg_%25.bbappend
>
> That's where github.com/JeffyCN/xorg-xserver and the AUTOREV are coming from.
>
Oh my yes. I was grepping around in meta-zephyr as it fails only there.
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168793):
https://lists.openembedded.org/g/openembedded-core/message/168793
Mute This Topic: https://lists.openembedded.org/mt/92692286/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4
On Tue, Aug 2, 2022 at 7:56 AM Marta Rybczynska wrote:
>
> On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman wrote:
> >
> > From: Alexander Kanavin
> >
> > Security update
> >
>
> With this update we're getting:
>
> Parsing recipes...WARNING:
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> Exception during build_dependencies for AUTOREV
> WARNING:
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> Error during finalise of
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> ERROR: ExpansionError during parsing
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> Traceback (most recent call last):
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> 249, in Git.urldata_init(ud= 0x7fc0cb054970>, d= 0x7fc0cafbd0d0>):
> > ud.setup_revisions(d)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1347, in FetchData.setup_revisions(d= object at 0x7fc0cafbd0d0>):
> for name in self.names:
> > self.revisions[name] = srcrev_internal_helper(self, d, name)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1212, in srcrev_internal_helper(ud= 0x7fc0cb054970>, d=,
> name='default'):
> if srcrev == "AUTOINC":
> > srcrev = ud.method.latest_revision(ud, d, name)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1624, in Git.latest_revision(ud= 0x7fc0cb054970>, d=,
> name='default'):
> except KeyError:
> > revs[key] = rev = self._latest_revision(ud, d, name)
> return rev
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> 752, in Git._latest_revision(ud= 0x7fc0cb054970>, d=,
> name='default'):
> return sha1
> > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git
> > repository in git ls-remote output for %s" % \
> (ud.unresolvedrev[name], ud.host+ud.path))
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> upstream git repository in git ls-remote output for
> github.com/JeffyCN/xorg-xserver
> The variable dependency chain for the failure is: SRCPV ->
> AUTOREV[vardepvalue]
>
Additional information: it happens on zephyr and freertos builds.
Regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168767):
https://lists.openembedded.org/g/openembedded-core/message/168767
Mute This Topic: https://lists.openembedded.org/mt/92692286/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4
On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman wrote:
>
> From: Alexander Kanavin
>
> Security update
>
With this update we're getting:
Parsing recipes...WARNING:
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
Exception during build_dependencies for AUTOREV
WARNING:
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
Error during finalise of
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
ERROR: ExpansionError during parsing
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
Traceback (most recent call last):
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
249, in Git.urldata_init(ud=, d=):
> ud.setup_revisions(d)
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1347, in FetchData.setup_revisions(d=):
for name in self.names:
> self.revisions[name] = srcrev_internal_helper(self, d, name)
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1212, in srcrev_internal_helper(ud=, d=,
name='default'):
if srcrev == "AUTOINC":
> srcrev = ud.method.latest_revision(ud, d, name)
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1624, in Git.latest_revision(ud=, d=,
name='default'):
except KeyError:
> revs[key] = rev = self._latest_revision(ud, d, name)
return rev
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
752, in Git._latest_revision(ud=, d=,
name='default'):
return sha1
> raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git repository
> in git ls-remote output for %s" % \
(ud.unresolvedrev[name], ud.host+ud.path))
bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
upstream git repository in git ls-remote output for
github.com/JeffyCN/xorg-xserver
The variable dependency chain for the failure is: SRCPV -> AUTOREV[vardepvalue]
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168766):
https://lists.openembedded.org/g/openembedded-core/message/168766
Mute This Topic: https://lists.openembedded.org/mt/92692286/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
