Since be0e796299b0 ("build: ship all config files with
--enable-datafiles") in bluez, installing input.conf and network.conf
has been redundant, as the bluez5 recipe already includes
--enable-datafiles.
Signed-off-by: Emil Kronborg
---
meta/recipes-connectivity/bluez5/bluez5.inc | 8
1
Socket activation is prone to DoS (denial of service) because too many
connections will permanently deactivate sshd.socket [1]. Also, since
socket units do not allow setting Restart, accepting new connections can
fail due to, for example, OOM (out of memory) [2]. Therefore, it seems
more sensible
On Fri, Mar 15, 2024 at 16:09 +, Ross Burton wrote:
> On 7 Mar 2024, at 20:08, Emil Kronborg via lists.openembedded.org
> wrote:
> >
> > Socket activation is prone to DoS (denial of service) because too many
> > connections will permanently deactivate sshd.socket [1]
Having only file as the CVE product is too generic. What we actually
want is file from file_project to match the correct CVE(s).
---
meta/recipes-devtools/file/file_5.45.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/file/file_5.45.bb
For some reason, the CVE product is just called py and not pytest in the
NIST NVD database. Since the database only accept keywords with at least
3 characters, the CVE vendor must also be specified.
---
meta/recipes-devtools/python/python3-pytest_8.0.2.bb | 2 ++
1 file changed, 2 insertions(+)
By specifying the CVE vendor as python, some CVEs are not found. For
instance, the CVE_PRODUCT for python3-pyopenssl becomes
python:pyopenssl, which yields no matches in the NIST NVD database
because the correct CVE vendor is pyopenssl.
Generally, CVE_PRODUCT ?= ${PYPI_PACKAGE}:${PYPI_PACKAGE}
By specifying the CVE vendor as python, some CVEs are not found. For
instance, the CVE_PRODUCT for python3-pyopenssl becomes
python:pyopenssl, which yields no matches in the NIST NVD database
because the correct CVE vendor is pyopenssl.
Generally, CVE_PRODUCT ?= ${PYPI_PACKAGE}:${PYPI_PACKAGE}
For some reason, the CVE product is just called py and not pytest in the
NIST NVD database. Since the database only accept keywords with at least
3 characters, the CVE vendor must also be specified.
Signed-off-by: Emil Kronborg
---
Changes in v2:
- I forgot to sign the first version.
Having only file as the CVE product is too generic. What we actually
want is file from file_project to match the correct CVE(s).
Signed-off-by: Emil Kronborg
---
Changes in v2:
- I forgot to sign the first version.
meta/recipes-devtools/file/file_5.45.bb | 2 ++
1 file changed, 2 insertions(+)
On Thu, Mar 21, 2024 at 17:10 +, Ross Burton wrote:
> I can only find two CVEs with the CPE pytest:py and either of them are
> actually related to the pytest package:
>
> https://nvd.nist.gov/vuln/detail/CVE-2020-29651
> https://nvd.nist.gov/vuln/detail/CVE-2022-42969
>
> These issues
On Thu, Mar 21, 2024 at 17:15 +, Ross Burton wrote:
> There’s also file:file, for example
> https://nvd.nist.gov/vuln/detail/CVE-2007-2799.
Hm, clicking on "Show Matching CPE(s)" gives no matches, which a search
also confirms. Searching for file_project:file yield results with
identical
On Thu, Mar 21, 2024 at 12:13 +, Richard Purdie wrote:
> I worry this is a misfiled CPE rather than general statement that
> they'd always use this for pytest CVEs. We might want to talk to them
> about tweaking it to be consistent? I'm certainly unsure about taking
> this patch as it might
On Thu, Mar 21, 2024 at 17:16 +, Ross Burton wrote:
> Have you got comparison reports for a world run before and after this change
> so we can see what the difference is?
No. After setting CVE_PRODUCT for around 5 python-* recipes, I noticed
a pattern, which led me to pypi.bbclass. Here, I
Signed-off-by: Emil Kronborg
---
meta/recipes-support/atk/at-spi2-core_2.52.0.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/atk/at-spi2-core_2.52.0.bb
b/meta/recipes-support/atk/at-spi2-core_2.52.0.bb
index cf221e038927..2ab42ba13f50 100644
---
Commit ad605662f1bc ("at-spi2-core: upgrade 2.44.1 -> 2.46.0") dropped
the at-spi2-atk recipe, because it was merged into at-spi2-core upstream
[1]. The PROVIDES variable was changed to also include at-spi2-atk, but
not CVE_PRODUCT.
[1]:
Commit ad605662f1bc ("at-spi2-core: upgrade 2.44.1 -> 2.46.0") dropped
the at-spi2-atk recipe, because it was merged into at-spi2-core upstream
[1]. The PROVIDES variable was changed to also include at-spi2-atk, but
not CVE_PRODUCT.
[1]:
On Wed, Apr 17, 2024 at 15:49 +, Ross Burton wrote:
> Don’t you mean +=? We care about issues against at-spi2-core too, surely.
>
> Ross
I was unable to find any (previous) CVEs for at-spi2-core, but I think
you are right. Also, at-spi2-atk was merged into at-spi2-core last year
[1], so
While the plus in GTK+ was dropped in GTK4 and onwards [1], it is still
necessary for GTK3. This is also reflected upstream where two versions
exist: http://ftp.gnome.org/pub/gnome/sources/gtk+ and
http://ftp.gnome.org/pub/gnome/sources/gtk.
[1]:
Using OVERRIDES in the check generates false positives in some
scenarios, for example when building binaries for an SDK supposed to run
on a 64-bit host. Therefore, it is more correct to use HOST_ARCH for the
check instead.
$ bitbake -c do_package_qa gcc-cross-canadian-arm
(...)
After commit cd25e5544ca3 ("insane: use HOST_ variables, not TARGET_ to
determine the cross system"), this check is no longer necessary. The
introduction of HOST_ variables ensures architecture compatibility is
correctly checked.
Signed-off-by: Emil Kronborg
---
The code that used these variable and the comment was introduced in
commit b44d32ef41ef ("insane.bbclass: Portions of code were not running,
fix this and sync with OE.dev. Also add tests for bad sysroot rpaths in
binaries"). Later, in commit 17dae13fabe2 ("insane.bbclass: Fix ELF
bitsize
Commit cd25e5544ca3 ("insane: use HOST_ variables, not TARGET_ to
determine the cross system") updated the variables themselves, but not
their names. To prevent confusion, match the Python variable name to the
BitBake variable name.
Signed-off-by: Emil Kronborg
---
On Thu, May 23, 2024 at 14:39 GMT, Richard Purdie wrote:
> This is not correct, e.g. HOST_ARCH does not always equal "x86" for 32
> bit x86 builds.
>
> $ MACHINE=qemux86 bitbake -e | grep ^OVERRIDES= -C 2
> # pre-expansion value:
> #
>
On Fri, May 24, 2024 at 09:49 GMT, Alexander Kanavin wrote:
> I vaguely remember that at some point I ran 'bitbake -e recipe'
> against qemux86 machine to study that question, and looked through all
> related variables, and couldn't find anything better. But you're
> welcome to try that as well.
24 matches
Mail list logo
