Drop backport CVE patches.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
...{checkpolicy_3.2.bb => checkpolicy_3.3.bb} | 0
...python_3.2.bb => libselinux-python_3.3.bb} | 0
.../{libselinux_3.2.bb => libselinux_3.3.bb} | 0
...{libsemanage_3.2.bb => libsemanage_3.3.bb} | 0
.../selinux/libsepol/CVE-2021-36084.patch | 99 -------------
.../selinux/libsepol/CVE-2021-36085.patch | 38 -----
.../selinux/libsepol/CVE-2021-36086.patch | 46 ------
.../{libsepol_3.2.bb => libsepol_3.3.bb} | 4 -
.../{mcstrans_3.2.bb => mcstrans_3.3.bb} | 0
...oreutils_3.2.bb => policycoreutils_3.3.bb} | 0
...{restorecond_3.2.bb => restorecond_3.3.bb} | 0
.../selinux/secilc/CVE-2021-36087.patch | 134 ------------------
.../selinux/{secilc_3.2.bb => secilc_3.3.bb} | 2 -
...elinux-dbus_3.2.bb => selinux-dbus_3.3.bb} | 0
...{selinux-gui_3.2.bb => selinux-gui_3.3.bb} | 0
...ux-python_3.2.bb => selinux-python_3.3.bb} | 0
...-sandbox_3.2.bb => selinux-sandbox_3.3.bb} | 0
recipes-security/selinux/selinux_common.inc | 2 +-
...ule-utils_3.2.bb => semodule-utils_3.3.bb} | 0
19 files changed, 1 insertion(+), 324 deletions(-)
rename recipes-security/selinux/{checkpolicy_3.2.bb => checkpolicy_3.3.bb} (100%)
rename recipes-security/selinux/{libselinux-python_3.2.bb => libselinux-python_3.3.bb} (100%)
rename recipes-security/selinux/{libselinux_3.2.bb => libselinux_3.3.bb} (100%)
rename recipes-security/selinux/{libsemanage_3.2.bb => libsemanage_3.3.bb} (100%)
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36084.patch
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36085.patch
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36086.patch
rename recipes-security/selinux/{libsepol_3.2.bb => libsepol_3.3.bb} (85%)
rename recipes-security/selinux/{mcstrans_3.2.bb => mcstrans_3.3.bb} (100%)
rename recipes-security/selinux/{policycoreutils_3.2.bb => policycoreutils_3.3.bb} (100%)
rename recipes-security/selinux/{restorecond_3.2.bb => restorecond_3.3.bb} (100%)
delete mode 100644 recipes-security/selinux/secilc/CVE-2021-36087.patch
rename recipes-security/selinux/{secilc_3.2.bb => secilc_3.3.bb} (90%)
rename recipes-security/selinux/{selinux-dbus_3.2.bb => selinux-dbus_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-gui_3.2.bb => selinux-gui_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-python_3.2.bb => selinux-python_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-sandbox_3.2.bb => selinux-sandbox_3.3.bb} (100%)
rename recipes-security/selinux/{semodule-utils_3.2.bb => semodule-utils_3.3.bb} (100%)

diff --git a/recipes-security/selinux/checkpolicy_3.2.bb b/recipes-security/selinux/checkpolicy_3.3.bb
similarity index 100%
rename from recipes-security/selinux/checkpolicy_3.2.bb
rename to recipes-security/selinux/checkpolicy_3.3.bb
diff --git a/recipes-security/selinux/libselinux-python_3.2.bb b/recipes-security/selinux/libselinux-python_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libselinux-python_3.2.bb
rename to recipes-security/selinux/libselinux-python_3.3.bb
diff --git a/recipes-security/selinux/libselinux_3.2.bb b/recipes-security/selinux/libselinux_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libselinux_3.2.bb
rename to recipes-security/selinux/libselinux_3.3.bb
diff --git a/recipes-security/selinux/libsemanage_3.2.bb b/recipes-security/selinux/libsemanage_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libsemanage_3.2.bb
rename to recipes-security/selinux/libsemanage_3.3.bb
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36084.patch b/recipes-security/selinux/libsepol/CVE-2021-36084.patch
deleted file mode 100644
index 1001563..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36084.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-From f34d3d30c8325e4847a6b696fe7a3936a8a361f3 Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:01 -0400
-Subject: [PATCH] libsepol/cil: Destroy classperms list when resetting
- classpermission
-
-Nicolas Iooss reports:
- A few months ago, OSS-Fuzz found a crash in the CIL compiler, which
- got reported as
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28648 (the title
- is misleading, or is caused by another issue that conflicts with the
- one I report in this message). Here is a minimized CIL policy which
- reproduces the issue:
-
- (class CLASS (PERM))
- (classorder (CLASS))
- (sid SID)
- (sidorder (SID))
- (user USER)
- (role ROLE)
- (type TYPE)
- (category CAT)
- (categoryorder (CAT))
- (sensitivity SENS)
- (sensitivityorder (SENS))
- (sensitivitycategory SENS (CAT))
- (allow TYPE self (CLASS (PERM)))
- (roletype ROLE TYPE)
- (userrole USER ROLE)
- (userlevel USER (SENS))
- (userrange USER ((SENS)(SENS (CAT))))
- (sidcontext SID (USER ROLE TYPE ((SENS)(SENS))))
-
- (classpermission CLAPERM)
-
- (optional OPT
- (roletype nonexistingrole nonexistingtype)
- (classpermissionset CLAPERM (CLASS (PERM)))
- )
-
- The CIL policy fuzzer (which mimics secilc built with clang Address
- Sanitizer) reports:
-
- ==36541==ERROR: AddressSanitizer: heap-use-after-free on address
- 0x603000004f98 at pc 0x56445134c842 bp 0x7ffe2a256590 sp
- 0x7ffe2a256588
- READ of size 8 at 0x603000004f98 thread T0
- #0 0x56445134c841 in __cil_verify_classperms
- /selinux/libsepol/src/../cil/src/cil_verify.c:1620:8
- #1 0x56445134a43e in __cil_verify_classpermission
- /selinux/libsepol/src/../cil/src/cil_verify.c:1650:9
- #2 0x56445134a43e in __cil_pre_verify_helper
- /selinux/libsepol/src/../cil/src/cil_verify.c:1715:8
- #3 0x5644513225ac in cil_tree_walk_core
- /selinux/libsepol/src/../cil/src/cil_tree.c:272:9
- #4 0x564451322ab1 in cil_tree_walk
- /selinux/libsepol/src/../cil/src/cil_tree.c:316:7
- #5 0x5644513226af in cil_tree_walk_core
- /selinux/libsepol/src/../cil/src/cil_tree.c:284:9
- #6 0x564451322ab1 in cil_tree_walk
- /selinux/libsepol/src/../cil/src/cil_tree.c:316:7
- #7 0x5644512b88fd in cil_pre_verify
- /selinux/libsepol/src/../cil/src/cil_post.c:2510:7
- #8 0x5644512b88fd in cil_post_process
- /selinux/libsepol/src/../cil/src/cil_post.c:2524:7
- #9 0x5644511856ff in cil_compile
- /selinux/libsepol/src/../cil/src/cil.c:564:7
-
-The classperms list of a classpermission rule is created and filled
-in when classpermissionset rules are processed, so it doesn't own any
-part of the list and shouldn't retain any of it when it is reset.
-
-Destroy the classperms list (without destroying the data in it) when
-resetting a classpermission rule.
-
-Reported-by: Nicolas Iooss <nicolas.iooss@...>
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36084
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- libsepol/cil/src/cil_reset_ast.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: libsepol-3.0/cil/src/cil_reset_ast.c
-===================================================================
---- libsepol-3.0.orig/cil/src/cil_reset_ast.c
-+++ libsepol-3.0/cil/src/cil_reset_ast.c
-@@ -52,7 +52,7 @@ static void cil_reset_classpermission(st
- return;
- }
-
-- cil_reset_classperms_list(cp->classperms);
-+ cil_list_destroy(&cp->classperms, CIL_FALSE);
- }
-
- static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36085.patch b/recipes-security/selinux/libsepol/CVE-2021-36085.patch
deleted file mode 100644
index 4bd05eb..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36085.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From 2d35fcc7e9e976a2346b1de20e54f8663e8a6cba Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:04 -0400
-Subject: [PATCH] libsepol/cil: Destroy classperm list when resetting map perms
-
-Map perms share the same struct as regular perms, but only the
-map perms use the classperms field. This field is a pointer to a
-list of classperms that is created and added to when resolving
-classmapping rules, so the map permission doesn't own any of the
-data in the list and this list should be destroyed when the AST is
-reset.
-
-When resetting a perm, destroy the classperms list without destroying
-the data in the list.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36085
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- libsepol/cil/src/cil_reset_ast.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: libsepol-3.0/cil/src/cil_reset_ast.c
-===================================================================
---- libsepol-3.0.orig/cil/src/cil_reset_ast.c
-+++ libsepol-3.0/cil/src/cil_reset_ast.c
-@@ -34,7 +34,7 @@ static void cil_reset_class(struct cil_c
-
- static void cil_reset_perm(struct cil_perm *perm)
- {
-- cil_reset_classperms_list(perm->classperms);
-+ cil_list_destroy(&perm->classperms, CIL_FALSE);
- }
-
- static inline void cil_reset_classperms(struct cil_classperms *cp)
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36086.patch b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
deleted file mode 100644
index 7a2d616..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36086.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 49f9aa2a460fc95f04c99b44f4dd0d22e2f0e5ee Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:06 -0400
-Subject: [PATCH] libsepol/cil: cil_reset_classperms_set() should not reset
- classpermission
-
-In struct cil_classperms_set, the set field is a pointer to a
-struct cil_classpermission which is looked up in the symbol table.
-Since the cil_classperms_set does not create the cil_classpermission,
-it should not reset it.
-
-Set the set field to NULL instead of resetting the classpermission
-that it points to.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-[https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8]
-
-CVE: CVE-2021-36086
-
-Signed-off-by: Yi Zhao <yi.zhao@...>
----
- cil/src/cil_reset_ast.c | 6 +++++-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
-diff --git a/cil/src/cil_reset_ast.c b/cil/src/cil_reset_ast.c
-index 89f91e5..1d9ca70 100644
---- a/cil/src/cil_reset_ast.c
-+++ b/cil/src/cil_reset_ast.c
-@@ -59,7 +59,11 @@ static void cil_reset_classpermission(struct cil_classpermission *cp)
-
- static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
- {
-- cil_reset_classpermission(cp_set->set);
-+ if (cp_set == NULL) {
-+ return;
-+ }
-+
-+ cp_set->set = NULL;
- }
-
- static inline void cil_reset_classperms_list(struct cil_list *cp_list)
---
-2.17.1
-
diff --git a/recipes-security/selinux/libsepol_3.2.bb b/recipes-security/selinux/libsepol_3.3.bb
similarity index 85%
rename from recipes-security/selinux/libsepol_3.2.bb
rename to recipes-security/selinux/libsepol_3.3.bb
index 192f1b3..48d5f49 100644
--- a/recipes-security/selinux/libsepol_3.2.bb
+++ b/recipes-security/selinux/libsepol_3.3.bb
@@ -9,10 +9,6 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"

require selinux_common.inc

-SRC_URI += "file://CVE-2021-36084.patch \
- file://CVE-2021-36085.patch \
- file://CVE-2021-36086.patch "
-
inherit lib_package

S = "${WORKDIR}/git/libsepol"
diff --git a/recipes-security/selinux/mcstrans_3.2.bb b/recipes-security/selinux/mcstrans_3.3.bb
similarity index 100%
rename from recipes-security/selinux/mcstrans_3.2.bb
rename to recipes-security/selinux/mcstrans_3.3.bb
diff --git a/recipes-security/selinux/policycoreutils_3.2.bb b/recipes-security/selinux/policycoreutils_3.3.bb
similarity index 100%
rename from recipes-security/selinux/policycoreutils_3.2.bb
rename to recipes-security/selinux/policycoreutils_3.3.bb
diff --git a/recipes-security/selinux/restorecond_3.2.bb b/recipes-security/selinux/restorecond_3.3.bb
similarity index 100%
rename from recipes-security/selinux/restorecond_3.2.bb
rename to recipes-security/selinux/restorecond_3.3.bb
diff --git a/recipes-security/selinux/secilc/CVE-2021-36087.patch b/recipes-security/selinux/secilc/CVE-2021-36087.patch
deleted file mode 100644
index 5410477..0000000
--- a/recipes-security/selinux/secilc/CVE-2021-36087.patch
+++ /dev/null
@@ -1,134 +0,0 @@
-From bad0a746e9f4cf260dedba5828d9645d50176aac Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Mon, 19 Apr 2021 09:06:15 -0400
-Subject: [PATCH] secilc/docs: Update the CIL documentation for various blocks
-
-Update the documentation for macros, booleans, booleanifs, tunables,
-tunableifs, blocks, blockabstracts, blockinherits, and optionals to
-tell where these statements can be used and, for those that have
-blocks, what statements are not allowed in them.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36087
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- docs/cil_call_macro_statements.md | 2 ++
- docs/cil_conditional_statements.md | 6 +++++
- docs/cil_container_statements.md | 28 +++++++++++++++--------
- 3 files changed, 26 insertions(+), 10 deletions(-)
-
-Index: secilc/docs/cil_call_macro_statements.md
-===================================================================
---- secilc.orig/docs/cil_call_macro_statements.md
-+++ secilc/docs/cil_call_macro_statements.md
-@@ -58,6 +58,8 @@ When resolving macros the following plac
-
- - Items defined in the global namespace
-
-+[`tunable`](cil_conditional_statements.md#tunable), [`in`](cil_container_statements.md#in), [`block`](cil_container_statements.md#block), [`blockinherit`](cil_container_statements.md#blockinherit), [`blockabstract`](cil_container_statements.md#blockabstract), and other [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in [`macro`](cil_call_macro_statements.md#macro) blocks.
-+
- **Statement definition:**
-
- ```secil
-Index: secilc/docs/cil_conditional_statements.md
-===================================================================
---- secilc.orig/docs/cil_conditional_statements.md
-+++ secilc/docs/cil_conditional_statements.md
-@@ -6,6 +6,8 @@ boolean
-
- Declares a run time boolean as true or false in the current namespace. The [`booleanif`](cil_conditional_statements.md#booleanif) statement contains the CIL code that will be in the binary policy file.
-
-+[`boolean`](cil_conditional_statements.md#boolean) are not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -126,6 +128,8 @@ Tunables are similar to booleans, howeve
-
- Note that tunables can be treated as booleans by the CIL compiler command line parameter `-P` or `--preserve-tunables` flags.
-
-+Since [`tunableif`](cil_conditional_statements.md#tunableif) statements are resolved first, [`tunable`](cil_conditional_statements.md#tunable) statements are not allowed in [`in`](cil_container_statements.md#in), [`macro`](cil_call_macro_statements.md#macro), [`optional`](cil_container_statements.md#optional), and [`booleanif`](cil_conditional_statements.md#booleanif) blocks. To simplify processing, they are also not allowed in [`tunableif`](cil_conditional_statements.md#tunableif) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -164,6 +168,8 @@ tunableif
-
- Compile time conditional statement that may or may not add CIL statements to be compiled.
-
-+If tunables are being treated as booleans (by using the CIL compiler command line parameter `-P` or `--preserve-tunables` flag), then only the statements allowed in a [`booleanif`](cil_conditional_statements.md#booleanif) block are allowed in a [`tunableif`](cil_conditional_statements.md#tunableif) block. Otherwise, [`tunable`](cil_conditional_statements.md#tunable) statements are not allowed in a [`tunableif`](cil_conditional_statements.md#tunableif) block.
-+
- **Statement definition:**
-
- ```secil
-Index: secilc/docs/cil_container_statements.md
-===================================================================
---- secilc.orig/docs/cil_container_statements.md
-+++ secilc/docs/cil_container_statements.md
-@@ -4,7 +4,11 @@ Container Statements
- block
- -----
-
--Start a new namespace where any CIL statement is valid.
-+Start a new namespace.
-+
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) and [`optional`](cil_container_statements.md#optional) blocks.
-+
-+[`sensitivity`](cil_mls_labeling_statements.md#sensitivity) and [`category`](cil_mls_labeling_statements.md#category) statements are not allowed in [`block`](cil_container_statements.md#block) blocks.
-
- **Statement definition:**
-
-@@ -47,6 +51,8 @@ blockabstract
-
- Declares the namespace as a 'template' and does not generate code until instantiated by another namespace that has a [`blockinherit`](cil_container_statements.md#blockinherit) statement.
-
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) and [`optional`](cil_container_statements.md#optional) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -97,6 +103,8 @@ blockinherit
-
- Used to add common policy rules to the current namespace via a template that has been defined with the [`blockabstract`](cil_container_statements.md#blockabstract) statement. All [`blockinherit`](cil_container_statements.md#blockinherit) statements are resolved first and then the contents of the block are copied. This is so that inherited blocks will not be inherited. For a concrete example, please see the examples section.
-
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -199,15 +207,11 @@ This example contains a template `client
- optional
- --------
-
--Declare an [`optional`](cil_container_statements.md#optional) namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy. [`tunableif`](cil_conditional_statements.md#tunableif) and [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in optional containers. The same restrictions apply to CIL policy statements within [`optional`](cil_container_statements.md#optional)'s that apply to kernel policy statements, i.e. only the policy statements shown in the following table are valid:
-+Declare an [`optional`](cil_container_statements.md#optional) namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy.
-
--| | | | |
--| ------------------- | -------------- | ------------------ | ------------------ |
--| [`allow`](cil_access_vector_rules.md#allow) | [`allowx`](cil_access_vector_rules.md#allowx) | [`auditallow`](cil_access_vector_rules.md#auditallow) | [`auditallowx`](cil_access_vector_rules.md#auditallowx) |
--| [`booleanif`](cil_conditional_statements.md#booleanif) | [`dontaudit`](cil_access_vector_rules.md#dontaudit) | [`dontauditx`](cil_access_vector_rules.md#dontauditx) | [`typepermissive`](cil_type_statements.md#typepermissive) |
--| [`rangetransition`](cil_mls_labeling_statements.md#rangetransition) | [`role`](cil_role_statements.md#role) | [`roleallow`](cil_role_statements.md#roleallow) | [`roleattribute`](cil_role_statements.md#roleattribute) |
--| [`roletransition`](cil_role_statements.md#roletransition) | [`type`](cil_type_statements.md#type) | [`typealias`](cil_type_statements.md#typealias) | [`typeattribute`](cil_type_statements.md#typeattribute) |
--| [`typechange`](cil_type_statements.md#typechange) | [`typemember`](cil_type_statements.md#typemember) | [`typetransition`](cil_type_statements.md#typetransition) | |
-+Not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) blocks.
-+
-+[`tunable`](cil_conditional_statements.md#tunable), [`in`](cil_container_statements.md#in), [`block`](cil_container_statements.md#block), [`blockabstract`](cil_container_statements.md#blockabstract), and [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in [`optional`](cil_container_statements.md#optional) blocks.
-
- **Statement definition:**
-
-@@ -266,7 +270,11 @@ This example will instantiate the option
- in
- --
-
--Allows the insertion of CIL statements into a named container ([`block`](cil_container_statements.md#block), [`optional`](cil_container_statements.md#optional) or [`macro`](cil_call_macro_statements.md#macro)). This statement is not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) or [`tunableif`](cil_conditional_statements.md#tunableif) statements. This only works for containers that aren't inherited using [`blockinherit`](cil_conditional_statements.md#blockinherit).
-+Allows the insertion of CIL statements into a named container ([`block`](cil_container_statements.md#block), [`optional`](cil_container_statements.md#optional) or [`macro`](cil_call_macro_statements.md#macro)).
-+
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro), [`booleanif`](cil_conditional_statements.md#booleanif), and other [`in`](cil_container_statements.md#in) blocks.
-+
-+[`tunable`](cil_conditional_statements.md#tunable) and [`in`](cil_container_statements.md#in) statements are not allowed in [`in`](cil_container_statements.md#in) blocks.
-
- **Statement definition:**
-
diff --git a/recipes-security/selinux/secilc_3.2.bb b/recipes-security/selinux/secilc_3.3.bb
similarity index 90%
rename from recipes-security/selinux/secilc_3.2.bb
rename to recipes-security/selinux/secilc_3.3.bb
index 50413e0..60ab2fe 100644
--- a/recipes-security/selinux/secilc_3.2.bb
+++ b/recipes-security/selinux/secilc_3.3.bb
@@ -8,8 +8,6 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=c7e802b9a3b0c2c852669864c08b9138"

require selinux_common.inc

-SRC_URI += "file://CVE-2021-36087.patch"
-
DEPENDS += "libsepol xmlto-native"

S = "${WORKDIR}/git/secilc"
diff --git a/recipes-security/selinux/selinux-dbus_3.2.bb b/recipes-security/selinux/selinux-dbus_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-dbus_3.2.bb
rename to recipes-security/selinux/selinux-dbus_3.3.bb
diff --git a/recipes-security/selinux/selinux-gui_3.2.bb b/recipes-security/selinux/selinux-gui_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-gui_3.2.bb
rename to recipes-security/selinux/selinux-gui_3.3.bb
diff --git a/recipes-security/selinux/selinux-python_3.2.bb b/recipes-security/selinux/selinux-python_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-python_3.2.bb
rename to recipes-security/selinux/selinux-python_3.3.bb
diff --git a/recipes-security/selinux/selinux-sandbox_3.2.bb b/recipes-security/selinux/selinux-sandbox_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-sandbox_3.2.bb
rename to recipes-security/selinux/selinux-sandbox_3.3.bb
diff --git a/recipes-security/selinux/selinux_common.inc b/recipes-security/selinux/selinux_common.inc
index dc4ccd5..8bdf8ad 100644
--- a/recipes-security/selinux/selinux_common.inc
+++ b/recipes-security/selinux/selinux_common.inc
@@ -1,7 +1,7 @@
HOMEPAGE = "https://github.com/SELinuxProject"

SRC_URI = "git://github.com/SELinuxProject/selinux.git;branch=master;protocol=https"
-SRCREV = "cf853c1a0c2328ad6c62fb2b2cc55d4926301d6b"
+SRCREV = "7f600c40bc18d8180993edcd54daf45124736776"

UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+(\.\d+)+)"

diff --git a/recipes-security/selinux/semodule-utils_3.2.bb b/recipes-security/selinux/semodule-utils_3.3.bb
similarity index 100%
rename from recipes-security/selinux/semodule-utils_3.2.bb
rename to recipes-security/selinux/semodule-utils_3.3.bb
--
2.25.1

There are too many recipes in recipes-security/selinux. Keep the selinux
userspace recipes and move selinux scripts to selinux-scripts directory
to make the directory hierarchy clearer.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../selinux-autorelabel/selinux-autorelabel.service | 0
.../selinux-autorelabel/selinux-autorelabel.sh | 0
.../{selinux => selinux-scripts}/selinux-autorelabel_0.1.bb | 0
.../selinux-init/selinux-init.service | 0
.../{selinux => selinux-scripts}/selinux-init/selinux-init.sh | 0
.../selinux-init/selinux-init.sh.sysvinit | 0
recipes-security/{selinux => selinux-scripts}/selinux-init_0.1.bb | 0
recipes-security/{selinux => selinux-scripts}/selinux-initsh.inc | 0
.../selinux-labeldev/selinux-labeldev.service | 0
.../selinux-labeldev/selinux-labeldev.sh | 0
.../{selinux => selinux-scripts}/selinux-labeldev_0.1.bb | 0
11 files changed, 0 insertions(+), 0 deletions(-)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel/selinux-autorelabel.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel/selinux-autorelabel.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel_0.1.bb (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.sh.sysvinit (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init_0.1.bb (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-initsh.inc (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev/selinux-labeldev.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev/selinux-labeldev.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev_0.1.bb (100%)

diff --git a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.service b/recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.service
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.service
rename to recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.service
diff --git a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh b/recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.sh
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
rename to recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.sh
diff --git a/recipes-security/selinux/selinux-autorelabel_0.1.bb b/recipes-security/selinux-scripts/selinux-autorelabel_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel_0.1.bb
rename to recipes-security/selinux-scripts/selinux-autorelabel_0.1.bb
diff --git a/recipes-security/selinux/selinux-init/selinux-init.service b/recipes-security/selinux-scripts/selinux-init/selinux-init.service
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.service
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.service
diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh b/recipes-security/selinux-scripts/selinux-init/selinux-init.sh
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.sh
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.sh
diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit b/recipes-security/selinux-scripts/selinux-init/selinux-init.sh.sysvinit
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.sh.sysvinit
diff --git a/recipes-security/selinux/selinux-init_0.1.bb b/recipes-security/selinux-scripts/selinux-init_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-init_0.1.bb
rename to recipes-security/selinux-scripts/selinux-init_0.1.bb
diff --git a/recipes-security/selinux/selinux-initsh.inc b/recipes-security/selinux-scripts/selinux-initsh.inc
similarity index 100%
rename from recipes-security/selinux/selinux-initsh.inc
rename to recipes-security/selinux-scripts/selinux-initsh.inc
diff --git a/recipes-security/selinux/selinux-labeldev/selinux-labeldev.service b/recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.service
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev/selinux-labeldev.service
rename to recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.service
diff --git a/recipes-security/selinux/selinux-labeldev/selinux-labeldev.sh b/recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.sh
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev/selinux-labeldev.sh
rename to recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.sh
diff --git a/recipes-security/selinux/selinux-labeldev_0.1.bb b/recipes-security/selinux-scripts/selinux-labeldev_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev_0.1.bb
rename to recipes-security/selinux-scripts/selinux-labeldev_0.1.bb
--
2.25.1

Add RDEPENDS on audit-python for selinux-python-semanage.

Fixes:
$ semanage fcontext -a -t user_home_t "/web(/.*)?"
Traceback (most recent call last):
File "/usr/sbin/semanage", line 975, in <module>
do_parser()
File "/usr/sbin/semanage", line 947, in do_parser
args.func(args)
File "/usr/sbin/semanage", line 329, in handleFcontext
OBJECT.add(args.file_spec, args.type, args.ftype, args.range, args.seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2485, in add
self.__add(target, type, ftype, serange, seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2481, in __add
self.mylog.log_change("resrc=fcontext op=add %s ftype=%s tcontext=%s:%s:%s:%s"
% (audit.audit_encode_nv_string("tglob", target, 0), ftype_to_audit[ftype],)
NameError: name 'audit' is not defined

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-python_3.2.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-security/selinux/selinux-python_3.2.bb b/recipes-security/selinux/selinux-python_3.2.bb
index a954676..d130900 100644
--- a/recipes-security/selinux/selinux-python_3.2.bb
+++ b/recipes-security/selinux/selinux-python_3.2.bb
@@ -50,6 +50,7 @@ RDEPENDS:${BPN}-semanage += "\
python3-xml \
python3-misc \
libselinux-python \
+ audit-python \
${BPN} \
"
RDEPENDS:${BPN}-sepolicy += "\
--
2.25.1

Add branch and prototol to avoid do_fetch warnings.

Signed-off-by: Chen Qi <Qi.Chen@...>
---
recipes-tools/schedtool-dl/schedtool-dl.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb b/recipes-tools/schedtool-dl/schedtool-dl.bb
index 59e3b32..c8f5d1e 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -3,7 +3,7 @@ SECTION = "devel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=dc1f51f7ca94aebffb9b3663d82873ec"

-SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git \
+SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=https;branch=master \
file://0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch \
"
SRCREV = "3ffb479929c31cbae09de08f94f58b8f0f061d91"
--
2.33.0

On Tue, Dec 7, 2021 at 2:07 PM Greg Wilson-Lindberg
<gwilson@...> wrote:

We are building yocto Zeus for the Raspberrypi 4. We are using a touchscreen on the system, and it works just fine. But if a keyboard or mouse is plugged in when the system boots then the touchscreen is disabled.



I am wondering if there is a configuration somewhere that can be set to allow both the touchscreen and an external keyboard at the same time?

I wonder if its some overlap in device tree overlays

I’m sorry if this is the wrong forum to ask this, please point me in the right direction if not.

perhaps you can open a github issue here
https://github.com/agherzan/meta-raspberrypi/issues

Regards,

Greg Wilson-Lindberg

Hi Jon,

On 12/7/21 2:01 AM, Jon Mason wrote:

This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.

Definitely interested. I had already started contributing to
https://wiki.yoctoproject.org/wiki/Inclusive_language. Count me in.
Thanks
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

check

https://layers.openembedded.org/layerindex/branch/master/recipes/

if its not there then perhaps no one published it yet.

On Tue, Dec 7, 2021 at 1:45 AM <msabood2014@...> wrote:

Hi Guys i am new in YOCTO project. i have build images before and the images were included the "ls" and "clear" and all busybox commands. i do not know what happend now the image does not have anymore the "ls" or "clear" and all that commands and also there is a folder named && in the root directory ? What to do ?
Sorry if my question is stupid but i am just a new in Yocto and linux

try to see if /bin/ls exists. if its not there then maybe its deleted
somehow. best is to flash a new rootfs

On Tue, Dec 7, 2021 at 12:21 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi

On Tue, Dec 7, 2021 at 1:34 AM Richard Purdie
<richard.purdie@...> wrote:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.

confirmed by commenting out the echo above that that "solves the
issue", so it's in fact this code that is now wrongfully triggered.

I think Richard was suggesting that you add
REPRODUCIBLE_TIMESTAMP_ROOTFS to "" to your local.conf.

I did so and confirmed that /etc/version now has BUILDNAME for its
contents as expected.

Richard is correct that the patch was setting
REPRODUCIBLE_TIMESTAMP_ROOTFS incidentally. This part of Mark's patch
seems to be the cause:

-inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') ==
'1', 'reproducible_build_simple', '')}
+inherit reproducible_build_simple

And reproducible_build_simple does:

BUILD_REPRODUCIBLE_BINARIES = "1"

export PYTHONHASHSEED = "0"
export PERL_HASH_SEED = "0"
export SOURCE_DATE_EPOCH ??= "1520598896"

REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896"

So it is now overwriting what you've set in local.conf for
BUILD_REPRODUCIBLE_BINARIES. And if you look at your rootfs, you'll
probably see that all of the files are dated March 2019.

Master branch has restructured the code, but retained this behavior.

I'm not sure what the right answer is for dealing with the BUILDNAME
issue. Richard and Mark understand the reproducible build code far
better than I, perhaps they can offer an opinion on what to do here.

Steve

On Tue 2021-11-30 @ 06:27:53 PM, Khem Raj wrote:

Signed-off-by: Khem Raj <raj.khem@...>
---
README | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

Applied to meta-rockchip master branch. Thanks!

Hi

On Tue, Dec 7, 2021 at 1:34 AM Richard Purdie
<richard.purdie@...> wrote:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.

confirmed by commenting out the echo above that that "solves the
issue", so it's in fact this code that is now wrongfully triggered.

/ Henrik

Hi Guys i am new in YOCTO project. i have build images before and the images were included the "ls" and "clear" and all busybox commands. i do not know what happend now the image does not have anymore the "ls" or "clear" and all that commands and also there is a folder named && in the root directory ? What to do ?
Sorry if my question is stupid but i am just a new in Yocto and linux

Thanks a lot. That works perfectly, but do you know how to use the log commands inside the recipe? It seems they work inside functions only (`do_install` e.g.)

Hi
There is an old discussion regarding this in this link:
https://lists.frrouting.org/pipermail/frog/2019-January/000445.html
But I can't find any updated one. Is there an updated recipe to build FRR? 
Thanks

Hi

To get a value of some variable added in recipe it is best to use bitbake
with `-e` flag which should print the whole environment, then one can just
use `grep` to search for given variable. Let say we have recipe `example.bb`
and need to know the value of `A_VAR` - with bitbake you can find it with

`bitbake -e example | grep ^A_VAR`

Regards
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com

Hi
There is a variable (or what ever it's called) inside a recipe. I want to know its value.
I've used `bbnote "something"` but this gives a parse error.
How to properly log?

This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.

Thanks,
Jon