[meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@rootcommit.com>

This recipe is a Scarthgap backport of kernel-hardening-checker_0.6.10.2.bb
in the master branch as of August 19, 2025.

Tested on qemux86-64 and on beaglebone-yocto

Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
---
 ...ject.toml-fix-up-license-information.patch | 31 ++++++++++++++
 ...-relax-setuptool-version-requirement.patch | 29 +++++++++++++
 .../kernel-hardening-checker_0.6.10.2.bb      | 41 +++++++++++++++++++
 3 files changed, 101 insertions(+)
 create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
 create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
 create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb

diff --git a/meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch b/meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
new file mode 100644
index 0000000000..4460146722
--- /dev/null
+++ b/meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
@@ -0,0 +1,31 @@
+From e94c486c6c3473979ce5be627f030cc95ce165e6 Mon Sep 17 00:00:00 2001
+From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
+Date: Sun, 17 Aug 2025 17:27:21 +0200
+Subject: [PATCH 1/2] pyproject.toml: fix up license information
+
+Without this change, the Python tooling complains that you
+can't have both "license" and "license-files" settings in pyproject.toml.
+
+This issue doesn't happen any more with the Python tooling
+in master (as of August 2025), so it's irrelevant for upstream.
+
+Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
+Upstream-Status: Inappropriate [oe specific]
+---
+ pyproject.toml | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/pyproject.toml b/pyproject.toml
+index a0b75c3..79e710b 100644
+--- a/pyproject.toml
++++ b/pyproject.toml
+@@ -20,8 +20,7 @@ authors = [
+ maintainers = [
+   {name = "Alexander Popov", email = "alex.popov@linux.com"}
+ ]
+-license = "GPL-3.0-only"
+-license-files = ["LICENSE.txt"]
++license = { text = "GPL-3.0-only" }
+ classifiers = [
+     "Development Status :: 5 - Production/Stable",
+     "Topic :: Security",
diff --git a/meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch b/meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
new file mode 100644
index 0000000000..05a8126c4e
--- /dev/null
+++ b/meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
@@ -0,0 +1,29 @@
+From 7c64511d2dcb58bc4d83dd41667c1f9295ca9712 Mon Sep 17 00:00:00 2001
+From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
+Date: Tue, 19 Aug 2025 21:47:05 +0200
+Subject: [PATCH 2/2] pyproject.toml: relax setuptool version requirement
+
+To match with what's available in Scarthgap
+It turns out that setuptools 69 is sufficient for building this tool.
+The developer may have aligned the version with his testing environment.
+
+This patch is not needed on meta-openembedded master which has a recent enough
+version.
+
+Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
+Upstream-Status: Inappropriate [oe specific]
+---
+ pyproject.toml | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pyproject.toml b/pyproject.toml
+index 79e710b..a8b59d8 100644
+--- a/pyproject.toml
++++ b/pyproject.toml
+@@ -1,5 +1,5 @@
+ [build-system]
+-requires = ["setuptools >= 77.0.3"]
++requires = ["setuptools >= 69"]
+ build-backend = "setuptools.build_meta"
+ 
+ [tool.setuptools.packages.find]
diff --git a/meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb b/meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb
new file mode 100644
index 0000000000..c0ae0f0d3c
--- /dev/null
+++ b/meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb
@@ -0,0 +1,41 @@
+SUMMARY = "A tool for checking the security hardening options of the Linux kernel"
+DESCRIPTION = "\
+    There are plenty of security hardening options for the Linux kernel; Kconfig \
+    options (compile-time); Kernel cmdline arguments (boot-time); Sysctl \
+    parameters (runtime). A lot of them have to be enabled manually to make the \
+    system more secure which is difficult to track. This tool helps with this \
+    task by checking and reporting about the settings compared to a list of \
+    recommendation. \
+"
+HOMEPAGE = "https://github.com/a13xp0p0v/kernel-hardening-checker"
+BUGTRACKER = "https://github.com/a13xp0p0v/kernel-hardening-checker/issues"
+LICENSE = "GPL-3.0-only"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=d32239bcb673463ab874e80d47fae504"
+
+SRC_URI = "git://github.com/a13xp0p0v/kernel-hardening-checker;protocol=https;branch=master \
+	   file://0001-pyproject.toml-fix-up-license-information.patch \
+	   file://0002-pyproject.toml-relax-setuptool-version-requirement.patch"
+
+SRCREV = "0ebece346f187e7d3589883cc1d194fcd1c3cda8"
+
+S = "${WORKDIR}/git"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+RDEPENDS:${PN} = "\
+    python3-json \
+    python3-misc \
+    python3-compression \
+    bash \
+"
+
+# /boot/config is required for the analysis
+RRECOMMENDS:${PN}:class-target = "\
+    kernel-dev \
+"
+
+inherit python_setuptools_build_meta
+
+# allow to run on build host, if you don't want it in the image
+# oe-run-native kernel-hardening-checker-native kernel-hardening-checker ...
+BBCLASSEXTEND = "native"

Re: [oe] [meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[Gyorgy Sarvari]

On 8/19/25 22:39, Michael Opdenacker via lists.openembedded.org wrote:
> From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>
> This recipe is a Scarthgap backport of kernel-hardening-checker_0.6.10.2.bb
> in the master branch as of August 19, 2025.
>
> Tested on qemux86-64 and on beaglebone-yocto
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
> ---
>  ...ject.toml-fix-up-license-information.patch | 31 ++++++++++++++
>  ...-relax-setuptool-version-requirement.patch | 29 +++++++++++++
>  .../kernel-hardening-checker_0.6.10.2.bb      | 41 +++++++++++++++++++
>  3 files changed, 101 insertions(+)
>  create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
>  create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
>  create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb

Note that new recipes are only accepted in master branch, not in stable
branches.

Re: [oe] [meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[Michael Opdenacker]

Hi Gyorgy

Thanks for your reply!

On 8/20/25 09:44, Gyorgy Sarvari wrote:
> On 8/19/25 22:39, Michael Opdenacker via lists.openembedded.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>>
>> This recipe is a Scarthgap backport of kernel-hardening-checker_0.6.10.2.bb
>> in the master branch as of August 19, 2025.
>>
>> Tested on qemux86-64 and on beaglebone-yocto
>>
>> Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>> ---
>>   ...ject.toml-fix-up-license-information.patch | 31 ++++++++++++++
>>   ...-relax-setuptool-version-requirement.patch | 29 +++++++++++++
>>   .../kernel-hardening-checker_0.6.10.2.bb      | 41 +++++++++++++++++++
>>   3 files changed, 101 insertions(+)
>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb
> Note that new recipes are only accepted in master branch, not in stable
> branches.

However, this has already been accepted in master 
(https://git.openembedded.org/meta-openembedded/commit/?id=5ae3536204ba3764b03647ab75169ee65ca43531)
It's true that meta-oe didn't originally have this recipe, but what's 
the harm in sharing with LTS users that could have the same need as 
mine? The risk of breaking tests again meta-oe?

I'm reading https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS 
... I guess such a backport qualifies as a "new feature". But does this 
really apply to meta-openembedded which is not officially part of the LTS?

On the other hand, mixin layers are supposed to be for "potentially 
invasive changes", which is not the case here.
So, where are such (new) backports supposed to be shared?

Thanks
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/

Re: [oe] [meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[Gyorgy Sarvari]

On 8/20/25 10:04, Michael Opdenacker wrote:
> Hi Gyorgy
>
> Thanks for your reply!
>
> On 8/20/25 09:44, Gyorgy Sarvari wrote:
>> On 8/19/25 22:39, Michael Opdenacker via lists.openembedded.org wrote:
>>> From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>>>
>>> This recipe is a Scarthgap backport of kernel-hardening-checker_0.6.10.2.bb
>>> in the master branch as of August 19, 2025.
>>>
>>> Tested on qemux86-64 and on beaglebone-yocto
>>>
>>> Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>>> ---
>>>   ...ject.toml-fix-up-license-information.patch | 31 ++++++++++++++
>>>   ...-relax-setuptool-version-requirement.patch | 29 +++++++++++++
>>>   .../kernel-hardening-checker_0.6.10.2.bb      | 41 +++++++++++++++++++
>>>   3 files changed, 101 insertions(+)
>>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0001-pyproject.toml-fix-up-license-information.patch
>>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/files/0002-pyproject.toml-relax-setuptool-version-requirement.patch
>>>   create mode 100644 meta-oe/recipes-security/kernel-hardening-checker/kernel-hardening-checker_0.6.10.2.bb
>> Note that new recipes are only accepted in master branch, not in stable
>> branches.
> However, this has already been accepted in master 
> (https://git.openembedded.org/meta-openembedded/commit/?id=5ae3536204ba3764b03647ab75169ee65ca43531)
> It's true that meta-oe didn't originally have this recipe, but what's 
> the harm in sharing with LTS users that could have the same need as 
> mine? The risk of breaking tests again meta-oe?

At the end of the day it's of course the branch maintainer's call if he
accepts the extra recipe and the testing and maintenance tasks that come
with it, but I don't recall it happening in recent years. 

I think it would make precedent - if this recipe is accepted, why
wouldn't others be accepted? When does a small addition become an
unacceptably risky or big one? Stability is boring - and that's the
point. This of course is just the personal opinion of an internet rando
(me), and not official in any shape or form.

> I'm reading https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS 
> ... I guess such a backport qualifies as a "new feature". But does this 
> really apply to meta-openembedded which is not officially part of the LTS?
>
> On the other hand, mixin layers are supposed to be for "potentially 
> invasive changes", which is not the case here.
> So, where are such (new) backports supposed to be shared?

Such backports usually live in product specific layers (sometimes in
other community layers that take up the task of acting like a mixin
layer) until the project updates to a release that contains that recipe.

> Thanks
> Michael.
>

Re: [oe] [meta-oe][scarthgap][PATCH] kernel-hardening-checker: backport recipe

[Michael Opdenacker]

Greetings.

On 8/20/25 10:28, Gyorgy Sarvari via lists.openembedded.org wrote:
>> However, this has already been accepted in master
>> (https://git.openembedded.org/meta-openembedded/commit/?id=5ae3536204ba3764b03647ab75169ee65ca43531)
>> It's true that meta-oe didn't originally have this recipe, but what's
>> the harm in sharing with LTS users that could have the same need as
>> mine? The risk of breaking tests again meta-oe?
> At the end of the day it's of course the branch maintainer's call if he
> accepts the extra recipe and the testing and maintenance tasks that come
> with it, but I don't recall it happening in recent years.
>
> I think it would make precedent - if this recipe is accepted, why
> wouldn't others be accepted? When does a small addition become an
> unacceptably risky or big one? Stability is boring - and that's the
> point. This of course is just the personal opinion of an internet rando
> (me), and not official in any shape or form.
>
>> I'm reading https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
>> ... I guess such a backport qualifies as a "new feature". But does this
>> really apply to meta-openembedded which is not officially part of the LTS?
>>
>> On the other hand, mixin layers are supposed to be for "potentially
>> invasive changes", which is not the case here.
>> So, where are such (new) backports supposed to be shared?
> Such backports usually live in product specific layers (sometimes in
> other community layers that take up the task of acting like a mixin
> layer) until the project updates to a release that contains that recipe.

Any further objections to adding this backport to the scarthgap branch 
of meta-oe?

I guess there is no risk of breaking anything else in meta-oe/scarthgap, 
but if we don't want to accept exceptions to the rule (even for meta-oe 
which is not strictly part of the LTS), I'll create my own layer for LTS 
users who could be interested. I guess meta-security won't be a suitable 
candidate the upstream recipe is in meta-oe.

Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/