[PATCH 1/5] python3-certifi: set CVE_PRODUCT

[PATCH 1/5] python3-certifi: set CVE_PRODUCT

[mark.yang]

From: "mark.yang" <mark.yang@lge.com>

NVD tracks certifi as certifi:certifi, so the default python:certifi
vendor prefix never matches and its CVEs are not evaluated at all.
Use the exact vendor:product pair.

All three existing CVEs (CVE-2022-23491, CVE-2023-37920,
CVE-2024-39689) affect versions below 2026.6.17, so they resolve as
not affected; nothing new shows as unpatched.

Signed-off-by: mark.yang <mark.yang@lge.com>
---
 meta/recipes-devtools/python/python3-certifi_2026.6.17.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-certifi_2026.6.17.bb b/meta/recipes-devtools/python/python3-certifi_2026.6.17.bb
index db78aaea0c..69c505b510 100644
--- a/meta/recipes-devtools/python/python3-certifi_2026.6.17.bb
+++ b/meta/recipes-devtools/python/python3-certifi_2026.6.17.bb
@@ -11,6 +11,8 @@ SRC_URI[sha256sum] = "024c88eeec92ca068db80f02b8b07c9cef7b9fe261d1d535abfd5abd6f
 
 inherit pypi python_setuptools_build_meta
 
+CVE_PRODUCT = "certifi:certifi"
+
 BBCLASSEXTEND = "native nativesdk"
 
 RDEPENDS:${PN} += "python3-io"

[PATCH 2/5] python3-idna: set CVE_PRODUCT

[mark.yang]

From: "mark.yang" <mark.yang@lge.com>

The pypi class default python:idna matches nothing in the CVE
databases, which track the Python idna CVEs as:

* CVE-2024-3651 (kjd:internationalized_domain_names_in_applications) [1]
* CVE-2026-45409 (kjd:idna in the CNA record, same NVD CPE as above)

Set both vendor:product pairs. Both CVEs are fixed before 3.18, so
they resolve as not affected.

The bare product name is not an option here: it would also match
"servo:idna", the Rust idna crate (e.g. CVE-2024-12224).

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-3651

Signed-off-by: mark.yang <mark.yang@lge.com>
---
 meta/recipes-devtools/python/python3-idna_3.18.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-idna_3.18.bb b/meta/recipes-devtools/python/python3-idna_3.18.bb
index cac86a8594..70405819e7 100644
--- a/meta/recipes-devtools/python/python3-idna_3.18.bb
+++ b/meta/recipes-devtools/python/python3-idna_3.18.bb
@@ -10,4 +10,6 @@ inherit pypi python_flit_core ptest-python-pytest
 RDEPENDS:${PN} += "python3-codecs"
 RDEPENDS:${PN}-ptest += "python3-unittest-automake-output"
 
+CVE_PRODUCT = "kjd:idna kjd:internationalized_domain_names_in_applications"
+
 BBCLASSEXTEND = "native nativesdk"

[PATCH 3/5] python3-pyopenssl: set CVE_PRODUCT

[mark.yang]

From: "mark.yang" <mark.yang@lge.com>

The pypi class default python:pyopenssl matches nothing in the CVE
databases, which have used four vendor spellings for pyOpenSSL over
the years:

* CVE-2013-4314 (jean-paul_calderone:pyopenssl)
* CVE-2018-1000807 (pyopenssl:pyopenssl)
* CVE-2018-1000808 (pyopenssl_project:pyopenssl)
* CVE-2026-27448, CVE-2026-27459 (pyca:pyopenssl in the CNA records,
pyopenssl:pyopenssl in the NVD CPEs)

Set all four vendor:product pairs. All five CVEs are fixed before
26.3.0 (the two 2026 ones in 26.0.0), so they resolve as not
affected.

Signed-off-by: mark.yang <mark.yang@lge.com>
---
 meta/recipes-devtools/python/python3-pyopenssl_26.3.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-pyopenssl_26.3.0.bb b/meta/recipes-devtools/python/python3-pyopenssl_26.3.0.bb
index c27f0719d1..ca6754d462 100644
--- a/meta/recipes-devtools/python/python3-pyopenssl_26.3.0.bb
+++ b/meta/recipes-devtools/python/python3-pyopenssl_26.3.0.bb
@@ -18,4 +18,6 @@ RDEPENDS:${PN}:class-target = " \
 "
 RDEPENDS:${PN}-tests = "${PN}"
 
+CVE_PRODUCT = "jean-paul_calderone:pyopenssl pyca:pyopenssl pyopenssl:pyopenssl pyopenssl_project:pyopenssl"
+
 BBCLASSEXTEND = "native nativesdk"

[PATCH 4/5] python3-pyyaml: set CVE_PRODUCT

[mark.yang]

From: "mark.yang" <mark.yang@lge.com>

The pypi class default python:pyyaml vendor prefix matches nothing,
so PyYAML CVEs are not evaluated at all. The databases use two
vendor spellings: pyyaml in the NVD CPEs, and "Red Hat" (with a
space, not expressible as a vendor:product pair) in CVE-2020-1747's
CNA record. Use the bare product name to cover both.

All four existing CVEs (CVE-2017-18342, CVE-2019-20477,
CVE-2020-1747, CVE-2020-14343) are fixed by 5.4, so they resolve as
not affected at 6.0.3.

Signed-off-by: mark.yang <mark.yang@lge.com>
---
 meta/recipes-devtools/python/python3-pyyaml_6.0.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-pyyaml_6.0.3.bb b/meta/recipes-devtools/python/python3-pyyaml_6.0.3.bb
index 7e2b088ca5..849e2c9cc8 100644
--- a/meta/recipes-devtools/python/python3-pyyaml_6.0.3.bb
+++ b/meta/recipes-devtools/python/python3-pyyaml_6.0.3.bb
@@ -21,4 +21,6 @@ RDEPENDS:${PN} += "\
     python3-netclient \
 "
 
+CVE_PRODUCT = "pyyaml"
+
 BBCLASSEXTEND = "native nativesdk"

[PATCH 5/5] python3-xmltodict: set CVE_PRODUCT

[mark.yang]

From: "mark.yang" <mark.yang@lge.com>

The CVE databases track xmltodict as xmltodict:xmltodict, so the
default python:xmltodict vendor prefix never matches and its CVEs
are not evaluated at all. Use the exact vendor:product pair.

The only existing CVE (CVE-2025-9375, disputed by upstream) affects
0.14.2 before 0.15.1, so it resolves as not affected at 1.0.4.

Signed-off-by: mark.yang <mark.yang@lge.com>
---
 meta/recipes-devtools/python/python3-xmltodict_1.0.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-xmltodict_1.0.4.bb b/meta/recipes-devtools/python/python3-xmltodict_1.0.4.bb
index e622c00dae..04632de099 100644
--- a/meta/recipes-devtools/python/python3-xmltodict_1.0.4.bb
+++ b/meta/recipes-devtools/python/python3-xmltodict_1.0.4.bb
@@ -7,6 +7,8 @@ SRC_URI[sha256sum] = "6d94c9f834dd9e44514162799d344d815a3a4faec913717a9ecbfa5be1
 
 PYPI_PACKAGE = "xmltodict"
 
+CVE_PRODUCT = "xmltodict:xmltodict"
+
 BBCLASSEXTEND = "native nativesdk"
 
 inherit pypi python_setuptools_build_meta ptest-python-pytest