[yocto] [meta-rockchip][PATCH] trusted-firmware-a: Add missing Upstream-Status

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../files/0001-dram-Fix-build-with-gcc-11.patch  | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch 
b/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
index 14defed..120ea0b 100644
--- a/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
+++ b/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
@@ -11,6 +11,7 @@ plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c:781:11: 
error: explicitly a
 twr_tmp = twr_tmp;
 ~~~ ^ ~~~
 
+Upstream-Status: Pending
 Signed-off-by: Khem Raj 
 ---
  plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c | 2 +-
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60391): https://lists.yoctoproject.org/g/yocto/message/60391
Mute This Topic: https://lists.yoctoproject.org/mt/99688580/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH] dm-verity-image-initramfs: Allow compressed image types

[Armin Kuster]

this fails to build:

The stack trace of python calls that resulted in this exception/failure was:
File: '', lineno: 24, function: 
0020:__anon_70__home_akuster_oss_clean_poky_meta_classes_recipe_rootfs_postcommands_bbclass(d)
0021:__anon_125__home_akuster_oss_clean_poky_meta_classes_recipe_image_bbclass(d)
0022:__anon_181__home_akuster_oss_clean_poky_meta_classes_recipe_image_bbclass(d)
0023:__anon_518__home_akuster_oss_clean_poky_meta_classes_recipe_image_bbclass(d)
 *** 
0024:__anon_28__home_akuster_oss_maint_meta_security_recipes_core_images_dm_verity_image_initramfs_bb(d)
File: 
'/home/akuster/oss/maint/meta-security/recipes-core/images/dm-verity-image-initramfs.bb', 
lineno: 26, function: 
__anon_28__home_akuster_oss_maint_meta_security_recipes_core_images_dm_verity_image_initramfs_bb

 0022:python __anonymous() {
 0023:    verity_image = d.getVar('DM_VERITY_IMAGE')
 0024:    verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
 0025:
 *** 0026:    dep = ' %s:do_image_%s' % (verity_image, 
verity_type.replace('-', '_'))

 0027:    d.appendVarFlag('do_image', 'depends', dep)
 0028:}
 0029:
 0030:# Ensure dm-verity.env is updated also when rebuilding 
DM_VERITY_IMAGE

Exception: AttributeError: 'NoneType' object has no attribute 'replace


On 6/19/23 2:57 AM, Stephan Wurm wrote:

Using  in the depends variable does not work for
compressed image types like squashfs-zst, as the resulting task
dependency still contains the incompatible dash. Replacing the dash by
an underscore resolves this issue.

Signed-off-by: Stephan Wurm 
---
  recipes-core/images/dm-verity-image-initramfs.bb | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/recipes-core/images/dm-verity-image-initramfs.bb 
b/recipes-core/images/dm-verity-image-initramfs.bb
index 187aeae..fc12ba0 100644
--- a/recipes-core/images/dm-verity-image-initramfs.bb
+++ b/recipes-core/images/dm-verity-image-initramfs.bb
@@ -19,7 +19,13 @@ IMAGE_FEATURES = ""
  IMAGE_LINGUAS = ""
  
  # Can we somehow inspect reverse dependencies to avoid these variables?

-do_image[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"
+python __anonymous() {
+verity_image = d.getVar('DM_VERITY_IMAGE')
+verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
+
+dep = ' %s:do_image_%s' % (verity_image, verity_type.replace('-', '_'))
+d.appendVarFlag('do_image', 'depends', dep)
+}
  
  # Ensure dm-verity.env is updated also when rebuilding DM_VERITY_IMAGE

  do_image[nostamp] = "1"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60390): https://lists.yoctoproject.org/g/yocto/message/60390
Mute This Topic: https://lists.yoctoproject.org/mt/99618767/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 1/2] clamav: drop unused patch

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-scanners/clamav/files/test.patch | 26 
 1 file changed, 26 deletions(-)
 delete mode 100644 recipes-scanners/clamav/files/test.patch

diff --git a/recipes-scanners/clamav/files/test.patch 
b/recipes-scanners/clamav/files/test.patch
deleted file mode 100644
index 8d94863..000
--- a/recipes-scanners/clamav/files/test.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-Upstream-Status: Pending
-
-Index: clamav-0.103.0/Makefile.am
-===
 clamav-0.103.0.orig/Makefile.am
-+++ clamav-0.103.0/Makefile.am
-@@ -28,7 +28,6 @@ else
- SUBDIRS = libltdl libclamav shared libfreshclam clamscan clamd clamdscan 
freshclam sigtool clamconf database docs etc clamav-milter test clamdtop clambc 
unit_tests
- EXTRA_DIST = examples shared libclamav.pc.in COPYING.bzip2 COPYING.lzma 
COPYING.unrar COPYING.LGPL COPYING.llvm COPYING.file COPYING.zlib 
COPYING.getopt COPYING.regex COPYING.YARA COPYING.pcre platform.h.in 
libclamunrar libclamunrar_iface libclammspack clamdscan/clamdscan.map win32 
ChangeLog.md INSTALL.cmake.md INSTALL.autotools.md NEWS.md README.md cmake 
CMakeLists.txt CMakeOptions.cmake $(top_srcdir)/**/CMakeLists.txt 
libclammspack/config.h.in.cmake clamav-config.h.cmake.in target.h.cmake.in 
autogen.sh
- 
--bin_SCRIPTS=clamav-config
- 
- if BUILD_CLAMONACC
- SUBDIRS += clamonacc
-Index: clamav-0.103.0/Makefile.in
-===
 clamav-0.103.0.orig/Makefile.in
-+++ clamav-0.103.0/Makefile.in
-@@ -641,7 +641,6 @@ ACLOCAL_AMFLAGS = -I m4
- @BUILD_LIBCLAMAV_ONLY_TRUE@SUBDIRS = libclamav $(am__append_1) \
- @BUILD_LIBCLAMAV_ONLY_TRUE@   $(am__append_2) $(am__append_3)
- @BUILD_LIBCLAMAV_ONLY_FALSE@bin_SCRIPTS = clamav-config
--@BUILD_LIBCLAMAV_ONLY_TRUE@bin_SCRIPTS = clamav-config
- @BUILD_LIBCLAMAV_ONLY_FALSE@EXTRA_DIST = examples shared libclamav.pc.in 
COPYING.bzip2 COPYING.lzma COPYING.unrar COPYING.LGPL COPYING.llvm COPYING.file 
COPYING.zlib COPYING.getopt COPYING.regex COPYING.YARA COPYING.pcre 
platform.h.in libclamunrar libclamunrar_iface libclammspack 
clamdscan/clamdscan.map win32 ChangeLog.md INSTALL.cmake.md 
INSTALL.autotools.md NEWS.md README.md cmake CMakeLists.txt CMakeOptions.cmake 
$(top_srcdir)/**/CMakeLists.txt libclammspack/config.h.in.cmake 
clamav-config.h.cmake.in target.h.cmake.in autogen.sh
- pkgconfigdir = $(libdir)/pkgconfig
- pkgconfig_DATA = libclamav.pc
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60388): https://lists.yoctoproject.org/g/yocto/message/60388
Mute This Topic: https://lists.yoctoproject.org/mt/99687930/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 2/2] isic: fine tune Upstream-Status

[Armin Kuster]

These are changes I did so apply the appropriate label.

Signed-off-by: Armin Kuster 
---
 recipes-security/isic/files/configure_fix.patch | 5 ++---
 recipes-security/isic/files/isic-0.07-make.patch| 4 +---
 recipes-security/isic/files/isic-0.07-netinet.patch | 4 +---
 3 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-security/isic/files/configure_fix.patch 
b/recipes-security/isic/files/configure_fix.patch
index 801fe0c..ed2bf7a 100644
--- a/recipes-security/isic/files/configure_fix.patch
+++ b/recipes-security/isic/files/configure_fix.patch
@@ -1,8 +1,7 @@
-Upstream-Status: Pending
-
 isic: add with-libnet remove libnet test
 
-Inappropriate - builds fine on non-oe systems. We need to exlude
+Upstream-Status: Inappropriate [embedded specific]
+builds fine on non-oe systems. We need to exlude
 cross compile libnet test. Pass in the location for libnet.a. Path
 did not support mulitlib either.
 
diff --git a/recipes-security/isic/files/isic-0.07-make.patch 
b/recipes-security/isic/files/isic-0.07-make.patch
index 838c873..94349ce 100644
--- a/recipes-security/isic/files/isic-0.07-make.patch
+++ b/recipes-security/isic/files/isic-0.07-make.patch
@@ -1,8 +1,6 @@
-Upstream-Status: Pending
-
 isic: Fixup makefile to support destination
 
-Backport:
+Upstream-Status: Backport
 http://pkgs.fedoraproject.org/cgit/isic.git/tree/isic-0.07-make.patch
 
 Signed-off-by: Armin Kuster 
diff --git a/recipes-security/isic/files/isic-0.07-netinet.patch 
b/recipes-security/isic/files/isic-0.07-netinet.patch
index 4b03880..448ba68 100644
--- a/recipes-security/isic/files/isic-0.07-netinet.patch
+++ b/recipes-security/isic/files/isic-0.07-netinet.patch
@@ -1,8 +1,6 @@
-Upstream-Status: Pending
-
 isic: add missing header file
 
-Backport:
+Upstream-Status: Backport
 http://pkgs.fedoraproject.org/cgit/isic.git/tree/isic-0.07-netinet.patch
 
 Signed-off-by: Armin Kuster 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60389): https://lists.yoctoproject.org/g/yocto/message/60389
Mute This Topic: https://lists.yoctoproject.org/mt/99687931/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH] openscap: fix buildpaths issue

[Armin Kuster]

Hello Kai,

Can you rebase  this to the latest master. There was a layer reorg 
landed during the posting of this patch.


BR,
Armin

On 6/20/23 11:55 PM, Kai Kang wrote:

From: Kai Kang 

Variables PREFERRED_PYTHON_PATH and PYTHON3_PATH are set with
${PYTHON_EXECUTABLE}. For cross compile, ${PYTHON_EXECUTABLE} may point
to other path rather than standard dir such as /usr/bin. Then the
generated library file contains such path which should NOT. Update to
make variables PREFERRED_PYTHON_PATH and PYTHON3_PATH configurable to
fix buildpaths issue:

| WARNING: openscap-1.3.7-r0 do_package_qa: QA Issue: File
| /usr/lib/libopenscap.so.25.5.1 in package openscap contains reference
| to TMPDIR [buildpaths]

Signed-off-by: Kai Kang 
---
  ...ts.txt-make-2-variables-configurable.patch | 37 +++
  .../openscap/openscap_1.3.7.bb|  8 +++-
  2 files changed, 44 insertions(+), 1 deletion(-)
  create mode 100644 
meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch

diff --git 
a/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch
 
b/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch
new file mode 100644
index 000..953b0d9
--- /dev/null
+++ 
b/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch
@@ -0,0 +1,37 @@
+From f99c3f1f516a84d33794f8e3da59adea1a12ef54 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Tue, 20 Jun 2023 22:42:51 +0800
+Subject: [PATCH] CMakeLists.txt: make 2 variables configurable
+
+Variables PREFERRED_PYTHON_PATH and PYTHON3_PATH are set with
+${PYTHON_EXECUTABLE}. For cross compile, ${PYTHON_EXECUTABLE} may point
+to other path rather than standard dir such as /usr/bin. Then the
+generated library file contains such path which should NOT. Update to
+make variables PREFERRED_PYTHON_PATH and PYTHON3_PATH configurable to
+avoid such issue.
+
+Upstream-Status: Submitted [https://github.com/OpenSCAP/openscap/pull/1990]
+
+Signed-off-by: Kai Kang 
+---
+ CMakeLists.txt | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 5db014e77..74628cdd4 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -125,8 +125,8 @@ endif()
+ find_package(PythonInterp 3)
+ find_package(PythonLibs 3)
+
+-set(PREFERRED_PYTHON_PATH "${PYTHON_EXECUTABLE}")
+-set(PYTHON3_PATH "${PYTHON_EXECUTABLE}")
++set(PREFERRED_PYTHON_PATH "${PYTHON_EXECUTABLE}" CACHE PATH "Path to preferred 
Python")
++set(PYTHON3_PATH "${PYTHON_EXECUTABLE}" CACHE PATH "Path to Python3")
+
+ find_package(RPM)
+ if(RPM_FOUND)
+--
+2.34.1
+
diff --git 
a/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb 
b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb
index cfe93f0..5ad92d4 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb
@@ -7,7 +7,13 @@ require openscap.inc
  inherit systemd
  
  SRCREV = "55efbfda0f617e05862ab6ed4862e10dbee52b03"

-SRC_URI = 
"git://github.com/OpenSCAP/openscap.git;branch=maint-1.3;protocol=https"
+SRC_URI = 
"git://github.com/OpenSCAP/openscap.git;branch=maint-1.3;protocol=https \
+   file://0001-CMakeLists.txt-make-2-variables-configurable.patch \
+   "
+
+EXTRA_OECMAKE += "-DPREFERRED_PYTHON_PATH=${bindir}/python3 \
+  -DPYTHON3_PATH=${bindir}/python3 \
+  "
  
  SYSTEMD_PACKAGES = "${PN}"

  SYSTEMD_SERVICE:${PN} = "oscap-remediate.service"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60387): https://lists.yoctoproject.org/g/yocto/message/60387
Mute This Topic: https://lists.yoctoproject.org/mt/99670413/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH] scap-security-guide: bump the number of test that pass

[Armin Kuster]

Add a eval script.
Lets see how many checks pass out of the box

Signed-off-by: Armin Kuster 
---
 .../0001-standard.profile-expand-checks.patch | 228 ++
 .../scap-security-guide/files/run_eval.sh |   3 +
 .../scap-security-guide_0.1.67.bb |  12 +-
 3 files changed, 241 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-compliance/scap-security-guide/files/0001-standard.profile-expand-checks.patch
 create mode 100644 recipes-compliance/scap-security-guide/files/run_eval.sh

diff --git 
a/recipes-compliance/scap-security-guide/files/0001-standard.profile-expand-checks.patch
 
b/recipes-compliance/scap-security-guide/files/0001-standard.profile-expand-checks.patch
new file mode 100644
index 000..0621360
--- /dev/null
+++ 
b/recipes-compliance/scap-security-guide/files/0001-standard.profile-expand-checks.patch
@@ -0,0 +1,228 @@
+From 7af2da3bbe1d5b4cba89c6dae9ea267717b865ea Mon Sep 17 00:00:00 2001
+From: Armin Kuster 
+Date: Wed, 21 Jun 2023 07:46:38 -0400
+Subject: [PATCH] standard.profile: expand checks
+
+Signed-off-by: Armin Kuster 
+---
+ .../openembedded/profiles/standard.profile| 206 ++
+ 1 file changed, 206 insertions(+)
+
+diff --git a/products/openembedded/profiles/standard.profile 
b/products/openembedded/profiles/standard.profile
+index 44339d716c..877d1a3971 100644
+--- a/products/openembedded/profiles/standard.profile
 b/products/openembedded/profiles/standard.profile
+@@ -9,4 +9,210 @@ description: |-
+ selections:
+ - file_owner_etc_passwd
+ - file_groupowner_etc_passwd
++- service_crond_enabled
++- file_groupowner_crontab
++- file_owner_crontab
++- file_permissions_crontab
++- file_groupowner_cron_hourly
++- file_owner_cron_hourly
++- file_permissions_cron_hourly
++- file_groupowner_cron_daily
++- file_owner_cron_daily
++- file_permissions_cron_daily
++- file_groupowner_cron_weekly
++- file_owner_cron_weekly
++- file_permissions_cron_weekly
++- file_groupowner_cron_monthly
++- file_owner_cron_monthly
++- file_permissions_cron_monthly
++- file_groupowner_cron_d
++- file_owner_cron_d
++- file_permissions_cron_d
++- file_groupowner_cron_allow
++- file_owner_cron_allow
++- file_cron_deny_not_exist
++- file_groupowner_at_allow
++- file_owner_at_allow
++- file_at_deny_not_exist
++- file_permissions_at_allow
++- file_permissions_cron_allow
++- file_groupowner_sshd_config
++- file_owner_sshd_config
++- file_permissions_sshd_config
++- file_permissions_sshd_private_key
++- file_permissions_sshd_pub_key
++- sshd_set_loglevel_verbose
++- sshd_set_loglevel_info
++- sshd_max_auth_tries_value=4
++- sshd_set_max_auth_tries
++- sshd_disable_rhosts
++- disable_host_auth
++- sshd_disable_root_login
++- sshd_disable_empty_passwords
++- sshd_do_not_permit_user_env
++- sshd_idle_timeout_value=15_minutes
++- sshd_set_idle_timeout
++- sshd_set_keepalive
++- var_sshd_set_keepalive=0
++- sshd_set_login_grace_time
++- var_sshd_set_login_grace_time=60
++- sshd_enable_warning_banner
++- sshd_enable_pam
++- sshd_set_maxstartups
++- var_sshd_set_maxstartups=10:30:60
++- sshd_set_max_sessions
++- var_sshd_max_sessions=10
++- accounts_password_pam_minclass
++- accounts_password_pam_minlen
++- accounts_password_pam_retry
++- var_password_pam_minclass=4
++- var_password_pam_minlen=14
++- locking_out_password_attempts
++- accounts_password_pam_pwhistory_remember_password_auth
++- accounts_password_pam_pwhistory_remember_system_auth
++- var_password_pam_remember_control_flag=required
++- var_password_pam_remember=5
++- set_password_hashing_algorithm_systemauth
++- accounts_maximum_age_login_defs
++- var_accounts_maximum_age_login_defs=365
++- accounts_password_set_max_life_existing
++- accounts_minimum_age_login_defs
++- var_accounts_minimum_age_login_defs=7
++- accounts_password_set_min_life_existing
++- accounts_password_warn_age_login_defs
++- var_accounts_password_warn_age_login_defs=7
++- account_disable_post_pw_expiration
++- var_account_disable_post_pw_expiration=30
++- no_shelllogin_for_systemaccounts
++- accounts_tmout
++- var_accounts_tmout=15_min
++- accounts_root_gid_zero
++- accounts_umask_etc_bashrc
++- accounts_umask_etc_login_defs
++- use_pam_wheel_for_su
++- sshd_allow_only_protocol2
++- journald_forward_to_syslog
++- journald_compress
++- journald_storage
++- service_auditd_enabled
++- service_httpd_disabled
++- service_vsftpd_disabled
++- service_named_disabled
++- service_nfs_disabled
++- service_rpcbind_disabled
++- service_slapd_disabled
++- service_dhcpd_disabled
++- service_cups_disabled
++- service_ypserv_disabled
++- service_rsyncd_disabled
++- s

[yocto] [meta-security][PATCH 3/7] dm-verity: save veritysetup args beside runtime environment

[Paul Gortmaker via lists.yoctoproject.org]

We already have this directory to save the environment variable settings
so they can be copied into the initramfs for runtime setup.

There are quite a few veritysetup args, and the nature of storing the
hash data after the filesystem data in an "oversized" partition can be
error prone due to rounding, fencepost errors, etc.

Save a copy of what we used for ease of debug inspection, and for basic
cut and paste use in experimentation and tweaking.

Signed-off-by: Paul Gortmaker 
---
 classes/dm-verity-img.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index b279fa8..e190c87 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -34,7 +34,6 @@ DM_VERITY_IMAGE_HASH_BLOCK_SIZE ?= "4096"
 # any useful info) and feed the rest to a script.
 process_verity() {
 local ENV="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.env"
-install -d ${STAGING_VERITY_DIR}
 rm -f $ENV
 
 # Each line contains a key and a value string delimited by ':'. Read the
@@ -59,6 +58,9 @@ verity_setup() {
 local SIZE=$(stat --printf="%s" $INPUT)
 local OUTPUT=$INPUT.verity
 local SETUP_ARGS=""
+local 
SAVED_ARGS="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.args"
+
+install -d ${STAGING_VERITY_DIR}
 
 if [ ${DM_VERITY_IMAGE_DATA_BLOCK_SIZE} -ge 
${DM_VERITY_IMAGE_HASH_BLOCK_SIZE} ]; then
 align=${DM_VERITY_IMAGE_DATA_BLOCK_SIZE}
@@ -75,6 +77,8 @@ verity_setup() {
 --hash-offset=$SIZE format $OUTPUT $OUTPUT \
 "
 
+echo "veritysetup $SETUP_ARGS" > $SAVED_ARGS
+
 # Let's drop the first line of output (doesn't contain any useful info)
 # and feed the rest to another function.
 veritysetup $SETUP_ARGS | tail -n +2 | process_verity
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60383): https://lists.yoctoproject.org/g/yocto/message/60383
Mute This Topic: https://lists.yoctoproject.org/mt/99681424/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 2/7] dm-verity: restructure the veritysetup arg parsing

[Paul Gortmaker via lists.yoctoproject.org]

In making changes to the existing veritysetup arg list, it is harder to
see what the proposed change is since they are are glued together on one
long line.  Break them up so reviewing future unified diffs will be more
easy to visually parse.

This also makes it easier to temp. dump the args to a file for debugging.

In theory this should have no functional change.

Signed-off-by: Paul Gortmaker 
---
 classes/dm-verity-img.bbclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index d809985..b279fa8 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -58,6 +58,7 @@ verity_setup() {
 local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
 local SIZE=$(stat --printf="%s" $INPUT)
 local OUTPUT=$INPUT.verity
+local SETUP_ARGS=""
 
 if [ ${DM_VERITY_IMAGE_DATA_BLOCK_SIZE} -ge 
${DM_VERITY_IMAGE_HASH_BLOCK_SIZE} ]; then
 align=${DM_VERITY_IMAGE_DATA_BLOCK_SIZE}
@@ -68,9 +69,15 @@ verity_setup() {
 
 cp -a $INPUT $OUTPUT
 
+SETUP_ARGS=" \
+--data-block-size=${DM_VERITY_IMAGE_DATA_BLOCK_SIZE} \
+--hash-block-size=${DM_VERITY_IMAGE_HASH_BLOCK_SIZE} \
+--hash-offset=$SIZE format $OUTPUT $OUTPUT \
+"
+
 # Let's drop the first line of output (doesn't contain any useful info)
 # and feed the rest to another function.
-veritysetup --data-block-size=${DM_VERITY_IMAGE_DATA_BLOCK_SIZE} 
--hash-block-size=${DM_VERITY_IMAGE_HASH_BLOCK_SIZE} --hash-offset=$SIZE format 
$OUTPUT $OUTPUT | tail -n +2 | process_verity
+veritysetup $SETUP_ARGS | tail -n +2 | process_verity
 }
 
 VERITY_TYPES = " \
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60384): https://lists.yoctoproject.org/g/yocto/message/60384
Mute This Topic: https://lists.yoctoproject.org/mt/99681425/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 7/7] dm-verity: add sample systemd separate hash example and doc

[Paul Gortmaker via lists.yoctoproject.org]

Create a wks.in that allows an out-of-the-box build of a bootable
USB image using systemd and the hash data as a separate device or
partition.

A focus here was to ensure we used proper GPT names and GPT types,
and the GPT UUIDs that are based on splitting the root hash.

Signed-off-by: Paul Gortmaker 
---
 docs/dm-verity-systemd-hash-x86-64.txt| 43 +++
 wic/systemd-bootdisk-dmverity-hash.wks.in | 18 ++
 2 files changed, 61 insertions(+)
 create mode 100644 docs/dm-verity-systemd-hash-x86-64.txt
 create mode 100644 wic/systemd-bootdisk-dmverity-hash.wks.in

diff --git a/docs/dm-verity-systemd-hash-x86-64.txt 
b/docs/dm-verity-systemd-hash-x86-64.txt
new file mode 100644
index 000..673b810
--- /dev/null
+++ b/docs/dm-verity-systemd-hash-x86-64.txt
@@ -0,0 +1,43 @@
+dm-verity and x86-64 and systemd - separate hash device
+---
+
+Everything said in "dm-verity-systemd-x86-64.txt" applies here.
+However booting under QEMU is not tested - only on real hardware.
+So for your MACHINE you need to choose "genericx86-64".
+
+Also, you'll need to point at the hash specific WKS file:
+
+WKS_FILES += " systemd-bootdisk-dmverity-hash.wks.in"
+
+The fundamental difference is to use a separate device/partition for
+storage of the hash data -- instead of "hiding" it beyond the filesystem
+in what is essentially a 5-10% oversized partition.  This takes any manual
+math calculations of size/offset out of the picture, and uses the kernel's
+natural behaviour of compartmentalizing devices to ensure they are separate.
+
+The example hash.wks file added here essentially adds a hash-only partition
+directly after the filesystem partition.  So the filesystem partition is
+no longer "oversized" and no offsets are needed/used.
+
+Since we are now using multiple partitions, we make a better effort to use
+accepted GPT partition types and UUIDs based on the roothash.  This means
+easier sysadmin level use/debugging based on cfdisk output etc.
+
+Generating the separate root hash image is driven off enabling this:
+   DM_VERITY_SEPARATE_HASH = "1"
+
+Two other variables control the GPT UUIDs - set to x86-64 defaults:
+
+   DM_VERITY_ROOT_GUID ?= "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
+   DM_VERITY_RHASH_GUID ?= "2c7357ed-ebd2-46d9-aec1-23d437ec2bf5"
+
+See: 
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
+
+Finally, the UUIDs (not the "partition types" above) are based off of
+the root node hash value as per the systemd "autodetect" proposed standard.
+These will obviously change with every update/rebuild of the root image.
+
+While not strictly coupled to any functionality at this point in time, it
+does aid in easier debugging, and puts us in alignment with using systemd
+inside the initramfs to replace manual veritysetup like configuration we
+currently do in the initramfs today, should we decide to do so later on.
diff --git a/wic/systemd-bootdisk-dmverity-hash.wks.in 
b/wic/systemd-bootdisk-dmverity-hash.wks.in
new file mode 100644
index 000..e400593
--- /dev/null
+++ b/wic/systemd-bootdisk-dmverity-hash.wks.in
@@ -0,0 +1,18 @@
+# short-description:  Create an EFI disk image with systemd-boot and separate 
hash dm-verity
+# A dm-verity variant of the regular wks for IA machines. We need to fetch
+# the partition images from the IMGDEPLOYDIR as the rootfs source plugin will
+# not recreate the exact block device corresponding with the hash tree. We must
+# not alter the label or any other setting on the image.
+# Based on OE-core's systemd-bootdisk.wks and meta-security's 
beaglebone-yocto-verity.wks.in file
+#
+# This .wks only works with the dm-verity-img class and separate hash data. 
(DM_VERITY_SEPARATE_HASH)
+
+part /boot --source bootimg-efi 
--sourceparams="loader=systemd-boot,initrd=microcode.cpio" --ondisk sda --label 
msdos --active --align 1024 --use-uuid
+
+# include the root+hash part with the dynamic hash/UUIDs from the build.
+include ${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.${DM_VERITY_IMAGE_TYPE}.wks.in
+
+# add "console=ttyS0,115200" or whatever you need to the --append="..."
+bootloader --ptable gpt --timeout=5 --append="root=/dev/mapper/rootfs"
+
+part swap --ondisk sda --size 44 --label swap1 --fstype=swap --use-uuid
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60385): https://lists.yoctoproject.org/g/yocto/message/60385
Mute This Topic: https://lists.yoctoproject.org/mt/99681426/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 4/7] dm-verity: add support for hash storage on separate partition

[Paul Gortmaker via lists.yoctoproject.org]

There are essentially two ways for dealing with where to put the hash
data for dm-verity block integrity checks.

You can store both in a single partition, by using ~95% of the storage
space for the filesystem and the remaining 5% tail for the hash, or you
can use a completely separate partition (or even device) for storing the
hash data elsewhere.

Method A relies on using a hash offset argument during creation, which
is generally OK from a scripted use case but is error prone when run
from the command line and the offset calculated manually.

Method B has the advantage of using the basic partition/device
compartmentalization of the kernel to ensure the fs data doesn't
overwrite the hash or vice versa.  It takes any possible errors due to
math miscalculations completely off the table.

At the moment, our current support is hard coded to only support the
offset method A.  Here we add support for separate hash as per B.

As multiple partitions are now in play, we use the UUID creation
standard adopted by the systemd/verity community which implicitly links
the root and hash partitions by splitting the top roothash in two for
the UUIDs of the components.

This change optionally creates the separate hash file but no examples
use it yet.  Further commits will implement an example.

Signed-off-by: Paul Gortmaker 
---
 classes/dm-verity-img.bbclass | 60 +--
 1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index e190c87..8351ab2 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -10,11 +10,15 @@
 # assure data integrity, the root hash must be stored in a trusted location
 # or cryptographically signed and verified.
 #
+# Optionally, we can store the hash data on a separate device or partition
+# for improved compartmentalization and ease of use/deployment.
+#
 # Usage:
 # DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
 # DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
+# DM_VERITY_SEPARATE_HASH = "1" # optional; store hash on separate dev
 # IMAGE_CLASSES += "dm-verity-img"
-#
+
 # The resulting image can then be used to implement the device mapper block
 # integrity checking on the target device.
 
@@ -28,6 +32,9 @@ DM_VERITY_IMAGE_DATA_BLOCK_SIZE ?= "1024"
 # Define the hash block size to use in veritysetup.
 DM_VERITY_IMAGE_HASH_BLOCK_SIZE ?= "4096"
 
+# Should we store the hash data on a separate device/partition?
+DM_VERITY_SEPARATE_HASH ?= "0"
+
 # Process the output from veritysetup and generate the corresponding .env
 # file. The output from veritysetup is not very machine-friendly so we need to
 # convert it to some better format. Let's drop the first line (doesn't contain
@@ -50,6 +57,35 @@ process_verity() {
 
 # Add partition size
 echo "DATA_SIZE=$SIZE" >> $ENV
+
+# Add whether we are storing the hash data separately
+echo "SEPARATE_HASH=${DM_VERITY_SEPARATE_HASH}" >> $ENV
+
+# Configured for single partition use of veritysetup?  OK, we are done.
+if [ ${DM_VERITY_SEPARATE_HASH} -eq 0 ]; then
+return
+fi
+
+# Craft up the UUIDs that are part of the verity standard for root & hash
+# while we are here and in shell.  Re-read our output to get ROOT_HASH
+# and then cut it in 1/2 ; HI for data UUID and LO for hash-data UUID.
+# 
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
+
+ROOT_HASH=$(cat $ENV | grep ^ROOT_HASH | sed 's/ROOT_HASH=//' | tr a-f A-F)
+ROOT_HI=$(echo "obase=16;ibase=16;$ROOT_HASH/2^80" | /usr/bin/bc)
+ROOT_LO=$(echo "obase=16;ibase=16;$ROOT_HASH%2^80" | /usr/bin/bc)
+
+# Hyphenate as per UUID spec and as expected by wic+sgdisk parameters.
+# Prefix with leading zeros, in case hash chunks weren't using highest bits
+# "bc" needs upper case, /dev/disk/by-partuuid/ is lower case. 
+ROOT_UUID=$(echo $ROOT_HI | sed 's/.*\(.\{32\}\)$/\1/' | \
+sed 's/./-&/9;s/./-&/14;s/./-&/19;s/./-&/24' | tr A-F a-f )
+RHASH_UUID=$(echo $ROOT_LO | sed 's/.*\(.\{32\}\)$/\1/' | \
+sed 's/./-&/9;s/./-&/14;s/./-&/19;s/./-&/24' | tr A-F a-f )
+
+# Emit the values needed for a veritysetup run in the initramfs
+echo "ROOT_UUID=$ROOT_UUID" >> $ENV
+echo "RHASH_UUID=$RHASH_UUID" >> $ENV
 }
 
 verity_setup() {
@@ -57,6 +93,8 @@ verity_setup() {
 local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
 local SIZE=$(stat --printf="%s" $INPUT)
 local OUTPUT=$INPUT.verity
+local OUTPUT_HASH=$INPUT.verity
+local HASH_OFFSET=""
 local SETUP_ARGS=""
 local 
SAVED_ARGS="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.args"
 
@@ -69,12 +107,19 @@ verity_setup() {
 fi
 SIZE=$(expr \( $SIZE + $align - 1 \) / $align \* $align)
 
+# Assume some users may want separate hash vs. appended hash
+if [ ${DM_VERITY_SEPARATE_HASH} -eq 1 ]; then
+OUTPUT_H

[yocto] [meta-security][PATCH 6/7] dm-verity: hook separate hash into initramfs framework

[Paul Gortmaker via lists.yoctoproject.org]

The prior commits create the separate hash so now it is time to update
the initramfs framework so that veritysetup, which is responsible for
binding the data and hash, is aware of when separate hash is in use,
and can react accordingly.

The added code follows the existing appended hash code style, but is
considerably smaller because it doesn't have the large case statement
that supports all possible identification schemes (label, UUID, ...).

With the root hash split in two to create the respective partition
UUIDs, we know exactly how to identify it, and the UUIDs used.

Signed-off-by: Paul Gortmaker 
---
 .../initramfs-framework-dm/dmverity   | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/recipes-core/initrdscripts/initramfs-framework-dm/dmverity 
b/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
index 71afc91..1923490 100644
--- a/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
+++ b/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
@@ -8,12 +8,41 @@ dmverity_run() {
 DATA_SIZE="__not_set__"
 DATA_BLOCK_SIZE="__not_set__"
 ROOT_HASH="__not_set__"
+SEPARATE_HASH="__not_set__"
 
 . /usr/share/misc/dm-verity.env
 
 C=0
 delay=${bootparam_rootdelay:-1}
 timeout=${bootparam_roottimeout:-5}
+
+# we know exactly what we are looking for; don't need the wide hunt below
+if [ "${SEPARATE_HASH}" -eq "1" ]; then
+while [ ! -b "/dev/disk/by-partuuid/${ROOT_UUID}" ]; do
+if [ $(( $C * $delay )) -gt $timeout ]; then
+fatal "Root device (data) resolution failed"
+exit 1
+fi
+debug "Sleeping for $delay second(s) to wait for root data to 
settle..."
+sleep $delay
+C=$(( $C + 1 ))
+done
+
+veritysetup \
+--data-block-size=${DATA_BLOCK_SIZE} \
+create rootfs \
+/dev/disk/by-partuuid/${ROOT_UUID} \
+/dev/disk/by-partuuid/${RHASH_UUID} \
+${ROOT_HASH}
+
+mount \
+ -o ro \
+/dev/mapper/rootfs \
+${ROOTFS_DIR} || exit 2
+
+   return
+fi
+
 RDEV="$(realpath /dev/disk/by-partuuid/${bootparam_root#PARTUUID=} 
2>/dev/null)"
 while [ ! -b "${RDEV}" ]; do
 if [ $(( $C * $delay )) -gt $timeout ]; then
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60382): https://lists.yoctoproject.org/g/yocto/message/60382
Mute This Topic: https://lists.yoctoproject.org/mt/99681423/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 0/7] dm-verity: separate device for hash storage

[Paul Gortmaker via lists.yoctoproject.org]

The primary goal here is to enable storage of dm-verity hash on a separate
device/partition.

There are essentially two ways for dealing with where to put the hash data
for dm-verity block integrity checks.

You can store both in a single partition, by using ~95% of the storage space
for the filesystem and the remaining 5% tail for the hash, or you can use a
completely separate partition (or even device) for storing the hash data
elsewhere.

Method A relies on using a hash offset argument during creation, which is
generally OK from a scripted use case but is error prone when run from the
command line and the offset calculated manually.

Method B has the advantage of using the basic partition/device
compartmentalization of the kernel to ensure the fs data doesn't overwrite
the hash or vice versa.  It takes any possible errors due to math
miscalculations completely off the table.

I originally also was looking at the systemd "autoconfiguration" that only
needs the root hash on the boot line in order to autodetect the partitions
with the filesystem data and with the hash data.  However, that became a
bridge too far once I realized that using systemd instead of a simple /init
script in the initramfs was an unavoidable hard dependency.  While that is
apparently a thing, I couldn't find anyone doing it by default, even in the
desktop distro space.

That said, there are good ideas in how the autodetection is supported. Like
using partition UUIDs based on the root hash.  Setting proper GPT types that
reflect it is verity-root or verity-hash; setting sensible GPT names, etc.

So in addition to supporting a separate hash using our current script based
initramfs /init -- everything done here is done in a systemd autodetect
compatible way.  Meaning that if someone eventually tackles supporting a
systemd based /init in the initramfs, we'll have the separate hash and a
worked example that sets everything up in a compatible fashion for that.

A side benefit of doing that, is that if you run cfdisk (or similar) on
your output device after writing the wic image to it, you get useful info
on the decoding of the GPT types, see the GPT names, etc.

Testing: I boot tested the new separate hash support on both an older i7
desktop, and a slightly newer atom based netbook - using wic and a USB drive
with the included documented steps.  Since I'm touching files for our
existing appended hash, I also went back and tested that on the same two
machines.

Final note - astute reviewers may note a hard coded path to "bc" -- this is
done because even though we have "tr" at that phase of the build, we don't
have "bc" because it is a separate stand-alone package.  I've got general
agreement on IRC that adding our sysroot "bc" to that phase of the build
makes sense.  So once I've done that in oe, I'll circle back here and strip
off the paths - avoiding timing dependencies between oe and meta-security.

Paul Gortmaker (7):
  dm-verity: add descriptive strings for "wic list images"
  dm-verity: restructure the veritysetup arg parsing
  dm-verity: save veritysetup args beside runtime environment
  dm-verity: add support for hash storage on separate partition
  dm-verity: add wks.in fragment with dynamic build hash data
  dm-verity: hook separate hash into initramfs framework
  dm-verity: add sample systemd separate hash example and doc

 classes/dm-verity-img.bbclass | 94 ++-
 docs/dm-verity-systemd-hash-x86-64.txt| 43 +
 .../initramfs-framework-dm/dmverity   | 29 ++
 wic/beaglebone-yocto-verity.wks.in|  1 +
 wic/systemd-bootdisk-dmverity-hash.wks.in | 18 
 wic/systemd-bootdisk-dmverity.wks.in  |  1 +
 6 files changed, 184 insertions(+), 2 deletions(-)
 create mode 100644 docs/dm-verity-systemd-hash-x86-64.txt
 create mode 100644 wic/systemd-bootdisk-dmverity-hash.wks.in

-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60380): https://lists.yoctoproject.org/g/yocto/message/60380
Mute This Topic: https://lists.yoctoproject.org/mt/99681421/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 5/7] dm-verity: add wks.in fragment with dynamic build hash data

[Paul Gortmaker via lists.yoctoproject.org]

Export the dynamic build data for consumption in wic image generation.

It can either be included directly or manually parsed for useful chunks
in custom configurations people end up making.

For convenience, it is placed alongside the work-shared/dm-verity dir
where we already store the plain environment file and the veritysetup
formatting argument that was used.

There is a subtle thing going on here with respect to using an include,
which warrants a mention.  The wic (wks.in) stuff only has access to
normal Yocto/OE/bitbake variables.

So, instead of a fragment, say if you had:
   DM_VERITY_ROOT_HASH = "__not_set__"
and then later, did a:
   d.setVar("DM_VERITY_ROOT_HASH", value)
after the image was built, and the hash was known - that seems sane.

But the problem is that once you do that, your variables are tracked
by default, and bitbake/lib/bb/siggen.py will be angry with you for
changing metadata during a build.  In theory one should be able to avoid
this with BB_BASEHASH_IGNORE_VARS and "vardepsexclude" but it means more
exposed variables, and as much as I tried, I couldn't get this to work.

Creating a fragment with the dynamic data for inclusion avoids all that.
The wks template itself remains static, and hence doesn't trigger warns.

Signed-off-by: Paul Gortmaker 
---
 classes/dm-verity-img.bbclass | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index 8351ab2..045c860 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -18,6 +18,13 @@
 # DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
 # DM_VERITY_SEPARATE_HASH = "1" # optional; store hash on separate dev
 # IMAGE_CLASSES += "dm-verity-img"
+#
+# Using the GPT UUIDs specified in the standard can also be useful in that
+# they are displayed and translated in cfdisk output.
+#
+# DM_VERITY_ROOT_GUID = 
+# DM_VERITY_RHASH_GUID = 
+# 
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
 
 # The resulting image can then be used to implement the device mapper block
 # integrity checking on the target device.
@@ -35,12 +42,20 @@ DM_VERITY_IMAGE_HASH_BLOCK_SIZE ?= "4096"
 # Should we store the hash data on a separate device/partition?
 DM_VERITY_SEPARATE_HASH ?= "0"
 
+# These are arch specific.  We could probably intelligently auto-assign these?
+# Take x86-64 values as defaults. No impact on functionality currently.
+# See SD_GPT_ROOT_X86_64 and SD_GPT_ROOT_X86_64_VERITY in the spec.
+# Note - these are passed directly to sgdisk so hyphens needed.
+DM_VERITY_ROOT_GUID ?= "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
+DM_VERITY_RHASH_GUID ?= "2c7357ed-ebd2-46d9-aec1-23d437ec2bf5"
+
 # Process the output from veritysetup and generate the corresponding .env
 # file. The output from veritysetup is not very machine-friendly so we need to
 # convert it to some better format. Let's drop the first line (doesn't contain
 # any useful info) and feed the rest to a script.
 process_verity() {
 local ENV="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.env"
+local WKS_INC="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.wks.in"
 rm -f $ENV
 
 # Each line contains a key and a value string delimited by ':'. Read the
@@ -86,6 +101,14 @@ process_verity() {
 # Emit the values needed for a veritysetup run in the initramfs
 echo "ROOT_UUID=$ROOT_UUID" >> $ENV
 echo "RHASH_UUID=$RHASH_UUID" >> $ENV
+
+# Create wks.in fragment with build specific UUIDs for partitions.
+# Unfortunately the wks.in does not support line continuations...
+# First, the unappended filesystem data partition.
+echo 'part / --source rawcopy --ondisk sda 
--sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
 --part-name verityroot --part-type="${DM_VERITY_ROOT_GUID}"'" 
--uuid=\"$ROOT_UUID\"" > $WKS_INC
+
+# note: no default mount point for hash data partition
+echo 'part --source rawcopy --ondisk sda 
--sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.vhash"
 --part-name verityhash --part-type="${DM_VERITY_RHASH_GUID}"'" 
--uuid=\"$RHASH_UUID\"" >> $WKS_INC
 }
 
 verity_setup() {
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60379): https://lists.yoctoproject.org/g/yocto/message/60379
Mute This Topic: https://lists.yoctoproject.org/mt/99681416/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 1/7] dm-verity: add descriptive strings for "wic list images"

[Paul Gortmaker via lists.yoctoproject.org]

Without these one line descriptors and their associated marker prefix,
the output from "wic list images" only shows they are available as a
choice but w/o any description

Signed-off-by: Paul Gortmaker 
---
 wic/beaglebone-yocto-verity.wks.in   | 1 +
 wic/systemd-bootdisk-dmverity.wks.in | 1 +
 2 files changed, 2 insertions(+)

diff --git a/wic/beaglebone-yocto-verity.wks.in 
b/wic/beaglebone-yocto-verity.wks.in
index a1d7738..d2923de 100644
--- a/wic/beaglebone-yocto-verity.wks.in
+++ b/wic/beaglebone-yocto-verity.wks.in
@@ -3,6 +3,7 @@
 # Copyright (C) 2020 BayLibre SAS
 # Author: Bartosz Golaszewski 
 #
+# short-description: Create a u-SD image for beaglebone-black with dm-verity
 # A dm-verity variant of the regular wks for beaglebone black. We need to fetch
 # the partition images from the DEPLOY_DIR_IMAGE as the rootfs source plugin 
will
 # not recreate the exact block device corresponding with the hash tree. We must
diff --git a/wic/systemd-bootdisk-dmverity.wks.in 
b/wic/systemd-bootdisk-dmverity.wks.in
index a275a48..8466368 100644
--- a/wic/systemd-bootdisk-dmverity.wks.in
+++ b/wic/systemd-bootdisk-dmverity.wks.in
@@ -1,3 +1,4 @@
+# short-description:  Create an EFI disk image with systemd-boot and dm-verity
 # A dm-verity variant of the regular wks for IA machines. We need to fetch
 # the partition images from the IMGDEPLOYDIR as the rootfs source plugin will
 # not recreate the exact block device corresponding with the hash tree. We must
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60378): https://lists.yoctoproject.org/g/yocto/message/60378
Mute This Topic: https://lists.yoctoproject.org/mt/99681414/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] meta-arm-toolchain: SUPPORTED file not found #toolchain

[Jesus Jimenez Sanchez via lists.yoctoproject.org]

Hi,

After a few problems that took me a while to fix, I've now used a default poky 
with default configuration, and it builds just fine.

There must be something in one of my configuration files that appends that 
"image/local" at the end of WORKDIR, but I've search in entire folder and there 
are no references to that string.

Best regards,
Jesús Jiménez Sánchez

From: Ross Burton 
Sent: Tuesday 20 June 2023 14:52
To: Jesus Jimenez Sanchez 
Cc: Sumit Garg ; yocto@lists.yoctoproject.org 

Subject: Re: [yocto] meta-arm-toolchain: SUPPORTED file not found #toolchain

CAUTION: This email originated from outside of our organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


So there’s a lot of settings in that file.  Can you replicate with a default 
config as generated by poky?

Ross

> On 20 Jun 2023, at 14:44, Jesus Jimenez Sanchez 
>  wrote:
>
> Hello,
>
> I am using an absolute path there; I just removed it before posting on the 
> email thread.
>
> I have attached my local.conf here.
>
> Best regards,
> Jesús Jiménez SánchezFrom: Sumit Garg 
> Sent: Tuesday 20 June 2023 14:18
> To: Ross Burton 
> Cc: Jesus Jimenez Sanchez ; 
> yocto@lists.yoctoproject.org 
> Subject: Re: [yocto] meta-arm-toolchain: SUPPORTED file not found #toolchain
>  [You don't often get email from sumit.g...@linaro.org. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION: This email originated from outside of our organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> On Tue, 20 Jun 2023 at 18:06, Ross Burton  wrote:
> >
> > On 20 Jun 2023, at 13:08, Sumit Garg via lists.yoctoproject.org 
> >  wrote:
> > >
> > > On Mon, 19 Jun 2023 at 22:03, Jesus.JimenezSanchez via
> > > lists.yoctoproject.org
> > >  wrote:
> > >>
> > >> Hello, I'm trying to add the arm toolchain to my yocto project but I 
> > >> just got this error
> > >> ```
> > >> | cp: cannot stat 
> > >> '.../tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/external-arm-toolchain/2022.02-r0/image/local/SUPPORTED':
> > >>  No such file or directory
> > >> ```
> > >> It comes from the `external-arm-toolchain.bb` recipe. I've checked and 
> > >> the `SUPPORTED` file is in the right folder (the `files` folder where 
> > >> the `external-arm-toolchain.bb` file is). I haven't made any 
> > >> modifications to the meta-arm repo. I just cloned it and changed to 
> > >> branch `kirkstone`. After that, I have configured my local.conf with 
> > >> this:
> > >> ```
> > >> TCMODE = "external-arm"
> > >>
> > >> EXTERNAL_TOOLCHAIN = 
> > >> ".../gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf"
> > >> ```
> > >>
> > >
> > > Don't provide a relative path here. It should be an absolute path to
> > > your external toolchain install directory. This should resolve your
> > > issue.
> >
> > If that’s the issue, can you add a check for the path being absolute to the 
> > class?
> >
>
> Sure, see [1].
>
> [1] 
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fmeta-arm%2Fmessage%2F4809&data=05%7C01%7CJesus.JimenezSanchez%40verifone.com%7C8fdf8d44005f462cd9b208db71959a89%7C611a22d68c40495884e3ce47d8205d98%7C0%7C0%7C638228659596378789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c%2Fd7LXNot1v%2Bmy%2BU6ioRDcoot2Qb2wXgN5PlDGHEe6I%3D&reserved=0
>
> -Sumit
>
> > Ross
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60377): https://lists.yoctoproject.org/g/yocto/message/60377
Mute This Topic: https://lists.yoctoproject.org/mt/99626981/21656
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH] *.patch: add Upstream-Status to all patches

[Martin Jansa]

On Wed, Jun 21, 2023 at 3:42 PM akuster808  wrote:

> Hello Martin,
>

Hello Armin,

On 6/21/23 6:42 AM, Martin Jansa wrote:
> > There is new patch-status QA check in oe-core:
> >
> https://git.openembedded.org/openembedded-core/commit/?id=76a685bfcf927593eac67157762a53259089ea8a
> >
> > This is temporary work around just to hide _many_ warnings from
> > optional patch-status (if you add it to WARN_QA).
> >
> > This just added
> > Upstream-Status: Pending
> > everywhere without actually investigating what's the proper status.
> >
> > This is just to hide current QA warnings and to catch new .patch files
> being
> > added without Upstream-Status, but the number of Pending patches is now
> terrible:
> >
> > 0 (0%)meta-parsec
> > N/A (0%)meta-hardening
> > 1 (100%)meta-integrity
> > 15 (68%)meta-tpm
> > 27 (61%)meta-security
> >
> > Signed-off-by: Martin Jansa 
>
>
> > ---
> >   ...Do-not-get-generation-using-ioctl-when-evm_portable-.patch | 4 
> >   .../0001-create-tpm-key-support-well-known-key-option.patch   | 2 ++
> >   .../files/0002-libtpm-support-env-TPM_SRK_PW.patch| 2 ++
> >   ...tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch | 2 ++
> >   ...tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch | 2 ++
> >   .../recipes-tpm1/tpm-tools/files/tpm-tools-extendpcr.patch| 2 ++
> Those appear to be fine.
> >   .../openscap/files/0002-openembedded-add-Poky-distro.patch| 2 ++
> The openscap patches are being dropped as they got accepted upstream. I
> sent a patch last night to reflect that.
>
> I can drop this change.
> >   recipes-perl/perl/files/libwhisker2.patch | 2 ++
> >   recipes-scanners/clamav/files/test.patch  | 2 ++
> the "test.patch" isn't used anywhere so I can remove it later.
> >   .../ecryptfs-utils/files/define_musl_sword_type.patch | 2 ++
> This one is missing other standard patch information. Looks like a bit
> more cleanup is in order on my part.
> >   recipes-security/isic/files/configure_fix.patch   | 2 ++
> This patch contains "Inappropriate" to the Upstream-Status should
> Inappropriate [reason]  not pending.
> >   recipes-security/isic/files/isic-0.07-make.patch  | 2 ++
> This patch contains "Backport" so the Upstream-Status should be Backport
> not pending.
> >   recipes-security/isic/files/isic-0.07-netinet.patch   | 2 ++
> This patch contains "Backport" so the Upstream-Status should be Backport
> not pending.
>
> I can take those last six as-is and send a follow up tweaking as needed
> or you can send a V2. Your call.
>

I use only very small portion of meta-security (just selinux recipe), so if
you can do the fix-up yourself my CI&I will be grateful.

Regards,

thanks,
> Armin
> >   13 files changed, 28 insertions(+)
> >
> > diff --git
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
> b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
> > index 3624576..f0d8975 100644
> > ---
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
> > +++
> b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
> > @@ -13,6 +13,8 @@ ioctl is not supported by the filesystem.
> >
> >   Signed-off-by: Stefan Berger 
> >   ---
> > +Upstream-Status: Pending
> > +
> >src/evmctl.c | 2 +-
> >1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > @@ -30,6 +32,8 @@ index 6d2bb67..c35a28c 100644
> >   int fd = open(file, 0);
> >
> >   ---
> > +Upstream-Status: Pending
> > +
> >   2.39.2
> >
> >
> > diff --git
> a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
> b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
> > index bed8b92..e6068af 100644
> > ---
> a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
> > +++
> b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
> > @@ -1,3 +1,5 @@
> > +Upstream-Status: Pending
> > +
> >   commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
> >   Author: Junxian.Xiao 
> >   Date:   Wed Jun 19 18:57:13 2013 +0800
> > diff --git
> a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
> b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
> > index 2caaaf0..74def4f 100644
> > ---
> a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
> > +++
> b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
> > @@ -1,3 +1,5 @@
> > +Upstream-Status: Pending
>

Re: [yocto] [meta-security][PATCH] *.patch: add Upstream-Status to all patches

[Armin Kuster]

Hello Martin,

On 6/21/23 6:42 AM, Martin Jansa wrote:

There is new patch-status QA check in oe-core:
https://git.openembedded.org/openembedded-core/commit/?id=76a685bfcf927593eac67157762a53259089ea8a

This is temporary work around just to hide _many_ warnings from
optional patch-status (if you add it to WARN_QA).

This just added
Upstream-Status: Pending
everywhere without actually investigating what's the proper status.

This is just to hide current QA warnings and to catch new .patch files being
added without Upstream-Status, but the number of Pending patches is now 
terrible:

0 (0%)  meta-parsec
N/A (0%)meta-hardening
1 (100%)meta-integrity
15 (68%)meta-tpm
27 (61%)meta-security

Signed-off-by: Martin Jansa 




---
  ...Do-not-get-generation-using-ioctl-when-evm_portable-.patch | 4 
  .../0001-create-tpm-key-support-well-known-key-option.patch   | 2 ++
  .../files/0002-libtpm-support-env-TPM_SRK_PW.patch| 2 ++
  ...tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch | 2 ++
  ...tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch | 2 ++
  .../recipes-tpm1/tpm-tools/files/tpm-tools-extendpcr.patch| 2 ++

Those appear to be fine.

  .../openscap/files/0002-openembedded-add-Poky-distro.patch| 2 ++
The openscap patches are being dropped as they got accepted upstream. I 
sent a patch last night to reflect that.


I can drop this change.

  recipes-perl/perl/files/libwhisker2.patch | 2 ++
  recipes-scanners/clamav/files/test.patch  | 2 ++

the "test.patch" isn't used anywhere so I can remove it later.

  .../ecryptfs-utils/files/define_musl_sword_type.patch | 2 ++
This one is missing other standard patch information. Looks like a bit 
more cleanup is in order on my part.

  recipes-security/isic/files/configure_fix.patch   | 2 ++
This patch contains "Inappropriate" to the Upstream-Status should 
Inappropriate [reason]  not pending.

  recipes-security/isic/files/isic-0.07-make.patch  | 2 ++
This patch contains "Backport" so the Upstream-Status should be Backport 
not pending.

  recipes-security/isic/files/isic-0.07-netinet.patch   | 2 ++
This patch contains "Backport" so the Upstream-Status should be Backport 
not pending.


I can take those last six as-is and send a follow up tweaking as needed 
or you can send a V2. Your call.


thanks,
Armin

  13 files changed, 28 insertions(+)

diff --git 
a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
 
b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
index 3624576..f0d8975 100644
--- 
a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
+++ 
b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
@@ -13,6 +13,8 @@ ioctl is not supported by the filesystem.
  
  Signed-off-by: Stefan Berger 

  ---
+Upstream-Status: Pending
+
   src/evmctl.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
@@ -30,6 +32,8 @@ index 6d2bb67..c35a28c 100644

int fd = open(file, 0);
   
  ---

+Upstream-Status: Pending
+
  2.39.2
  
  
diff --git a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch

index bed8b92..e6068af 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
@@ -1,3 +1,5 @@
+Upstream-Status: Pending
+
  commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
  Author: Junxian.Xiao 
  Date:   Wed Jun 19 18:57:13 2013 +0800
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
index 2caaaf0..74def4f 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
@@ -1,3 +1,5 @@
+Upstream-Status: Pending
+
  commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
  Author: Junxian.Xiao 
  Date:   Wed Jun 19 18:57:13 2013 +0800
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
index cc8772d..732961d 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
+++ 
b/me

Re: [yocto] python3-speechrecognition building using yocto recipe #yocto

[Richard Purdie]

On Wed, 2023-06-21 at 04:10 -0700, lavkhush2...@gmail.com wrote:
> Hi all, 
> 
> I want to create .deb file of package python3-speechrecognition  , I 
> successfully builded natively on target board riscv platform and i
> copied binary from target board and with using  recipe i am copying
> binary in path: /usr/lib/python3.8/site-packages and trying  to
> create .deb file from using yocto environment.
> 
> speechrecognition recipe is-
> 
> DESCRIPTION = "speechrecognition Packages with dependencies library's
> "
>  
> LICENSE = "CLOSED"
>  
> SRC_URI += "file://speechrecognition"
>  
> S = "${WORKDIR}/speechrecognition"
>  
> do_install() {
>         install -d  ${D}${libdir}/
>         cp -r ${S}/lib/* ${D}${libdir}/
> }
>  
> FILES_${PN} += "${libdir}/*"
> 
> 
> I am facing one issue here:-
> 
> ERROR: speechrecognition-3.9.0-r0 do_populate_sysroot: Fatal errors occurred 
> in subprocesses:
> Command '['riscv64-oe-linux-strip', '--remove-section=.comment', 
> '--remove-section=.note', 
> '/home/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-linux/speechrecognition/3.9.0-r0/sysroot-destdir/usr/lib/python3.8/site-packages/flac-linux-x86']'
>  returned non-zero exit status 1.
> > Subprocess output:riscv64-oe-linux-strip: Unable to recognise the
> > format of the input file `/home/integration-
> > team/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-
> > linux/speechrecognition/3.9.0-r0/sysroot-
> > destdir/usr/lib/python3.8/site-packages/flac-linux-x86'


I'll make a wild guess that the binary in "flac-linux-x86" is an x86
one and the riscv strip doesn't like x86 binaries.

I suspect your riscv target device doesn't like them much either.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60374): https://lists.yoctoproject.org/g/yocto/message/60374
Mute This Topic: https://lists.yoctoproject.org/mt/99674007/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] python3-speechrecognition building using yocto recipe #yocto

[Alexander Kanavin]

That's not how it works. You need to write a recipe that cross-builds
the needed package from source. Taking prebuilt binaries from
elsewhere is asking for trouble, and not recommended even for
experienced developers.

Alex

On Wed, 21 Jun 2023 at 13:10,  wrote:
>
> Hi all,
>
> I want to create .deb file of package python3-speechrecognition  , I  
> successfully builded natively on target board riscv platform and i copied 
> binary from target board and with using  recipe i am copying binary in path: 
> /usr/lib/python3.8/site-packages and trying  to create .deb file from using 
> yocto environment.
>
> speechrecognition recipe is-
>
> DESCRIPTION = "speechrecognition Packages with dependencies library's "
>
> LICENSE = "CLOSED"
>
> SRC_URI += "file://speechrecognition"
>
> S = "${WORKDIR}/speechrecognition"
>
> do_install() {
> install -d  ${D}${libdir}/
> cp -r ${S}/lib/* ${D}${libdir}/
> }
>
> FILES_${PN} += "${libdir}/*"
>
>
> I am facing one issue here:-
>
> ERROR: speechrecognition-3.9.0-r0 do_populate_sysroot: Fatal errors occurred 
> in subprocesses:
> Command '['riscv64-oe-linux-strip', '--remove-section=.comment', 
> '--remove-section=.note', 
> '/home/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-linux/speechrecognition/3.9.0-r0/sysroot-destdir/usr/lib/python3.8/site-packages/flac-linux-x86']'
>  returned non-zero exit status 1.
>
> Subprocess output:riscv64-oe-linux-strip: Unable to recognise the format of 
> the input file 
> `/home/integration-team/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-linux/speechrecognition/3.9.0-r0/sysroot-destdir/usr/lib/python3.8/site-packages/flac-linux-x86'
>
> Can anyone help me in this, where i am wrong.
>
> T&R
> luvkhush
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60373): https://lists.yoctoproject.org/g/yocto/message/60373
Mute This Topic: https://lists.yoctoproject.org/mt/99674007/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] python3-speechrecognition building using yocto recipe #yocto

[lavkhush2208]

Hi all,

I want to create .deb file of package python3-speechrecognition  , I  
successfully builded natively on target board riscv platform and i copied 
binary from target board and with using  recipe i am copying binary in path: 
/usr/lib/python3.8/site-packages and trying  to create .deb file from using 
yocto environment.

speechrecognition recipe is-

*DESCRIPTION = "speechrecognition Packages with dependencies library's "*

*LICENSE = "CLOSED"*

*SRC_URI += "file://speechrecognition"*

*S = "${WORKDIR}/speechrecognition"*

*do_install() {*
*install -d  ${D}${libdir}/*
*cp -r ${S}/lib/* ${D}${libdir}/*
*}*

*FILES_${PN} += "${libdir}/*"

* I am facing one issue here:-

*ERROR: speechrecognition-3.9.0-r0 do_populate_sysroot: Fatal errors occurred 
in subprocesses:*
*Command '['riscv64-oe-linux-strip', '--remove-section=.comment', 
'--remove-section=.note', 
'/home/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-linux/speechrecognition/3.9.0-r0/sysroot-destdir/usr/lib/python3.8/site-packages/flac-linux-x86']'
 returned non-zero exit status 1.*

> 
> *Subprocess output:riscv64-oe-linux-strip: Unable to recognise the format
> of the input file
> `/home/integration-team/kush/khu/sources/khu-build/tmp-glibc/work/riscv64-oe-linux/speechrecognition/3.9.0-r0/sysroot-destdir/usr/lib/python3.8/site-packages/flac-linux-x86'
> * Can anyone help me in this, where i am wrong.
> 
> T&R
> luvkhush
> *
> *
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60372): https://lists.yoctoproject.org/g/yocto/message/60372
Mute This Topic: https://lists.yoctoproject.org/mt/99674007/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] File magic/sdk relocation

[Oleksiy Obitotskyy via lists.yoctoproject.org]

Hi,

I have problem with reproducibility of this issue.

What I did: build buildtools tarball and install it
Than build sdk with this buildtools tarball.


  1.  No changes. Buildtools tarball installed and relocated into.
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/bin/file point to 
file.file actual binary that use MAGIC
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/environment-setup.d/file.sh
 contains:
export 
MAGIC="/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc"
  2.   Fix file recipe as recommended with escaping dollar sign and reinstall 
tarball. Got strange results.
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/environment-setup.d/file.sh
 contains:
export 
MAGIC="OECORE_NATIVE_SYSROOT/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc",
 i.e.
proper path but OECORE_NATIVE_SYSROOT not replaced with value
  3.   Cleanup and retest option (a). Get proper path
export 
MAGIC="/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc"

And I can't reproduce the issue with magic path. Probably it was an issue on my 
side with inproper initialization or something.

But still even with proper path to the magic file I have initial issue:

ERROR: quilt-native-0.67-r0 do_populate_sysroot: Fatal errors occurred in 
subprocesses:
Command '['file', '-b', 
'/nobackup/oobitots/sdk-master/test-file/tmp/work/x86_64-linux/quilt-native/0.67-r0/sysroot-destdir/nobackup/oobitots/sdk-master/test-file/tmp/work/x86_64-linux/quilt-native/0.67-r0/recipe-sysroot-native/usr/share/quilt/compat/sendmail']'
 returned non-zero exit status 1.

It looks like 'file' executed during do_package is unable to find magic, so 
environment have no such MAGIC value.

Trying to test with bitbake quilt-native -c devshell

oobitots-> echo $MAGIC
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc
[/nobackup/oobitots/sdk-master/test-file/tmp/work/x86_64-linux/quilt-native/0.67-r0/quilt-0.67]
oobitots-> which file
/nobackup/oobitots/sdk-master/test-file/tmp/hosttools/file
[/nobackup/oobitots/sdk-master/test-file/tmp/work/x86_64-linux/quilt-native/0.67-r0/quilt-0.67]
oobitots-> file 
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/bin/file.file
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/usr/bin/file.file: 
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter 
/nobackup/oobitots/btt-master/sysroots/x86_64-xesdk-linux/lib/ld-linux-x86-64.so.2,
 BuildID[sha1]=a7344295f5f77b886e3bef6cab8e21ea6e8ad08b, for GNU/Linux 4.18.0, 
stripped

Regards,
Oleksiy


From: Alexander Kanavin 
Sent: Monday, June 19, 2023 19:27
To: alex.kana...@gmail.com 
Cc: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco) 
; yocto@lists.yoctoproject.org 

Subject: Re: [yocto] File magic/sdk relocation

On closer look, it should even say:
export MAGIC="\$OECORE_NATIVE_SYSROOT/usr/share/misc/magic.mgc"

If you can test this and confirm that it works, a patch would be welcome.

Alex

On Mon, 19 Jun 2023 at 18:55, Alexander Kanavin via
lists.yoctoproject.org 
wrote:
>
> I think there is a mistake in the file recipe (and rpm has the problem too):
>
> cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/file.sh
> export MAGIC="$OECORE_NATIVE_SYSROOT${datadir}/misc/magic.mgc"
> EOF
>
> $OECORE_NATIVE_SYSROOT should be prefixed with a \ to prevent shell
> variable expansion at build time.
>
> Can you check that the problem is then fixed?
>
> Alex
>
> On Mon, 19 Jun 2023 at 17:50, Oleksiy Obitotskyy via
> lists.yoctoproject.org 
> wrote:
> >
> > Hi,
> >
> > I'm working on master oe core master branch and run into problem with file 
> > for nativesdk (buildtools tarball).
> > File started to use MAGIC variable initialized from 
> > .../environment-setup.d/file.sh, like
> >
> > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc
> >
> > This path relocation does not covered by relocate_sdk.sh script.
> >
> > Commit that change behavior from wrapper that use relative path to 
> > environment variable with absolute path is:
> >
> > commit 47db876d09d9a4394048579c21d0b394450ce681
> > Author: Chen Qi 
> > Date:   Tue Jan 17 12:06:30 2023 +0800
> >
> > file: export MAGIC in SDK
> >
> > Previously, a wrapper is used for file, which adds '--magic-file'
> > option to it. But other components might use libmagic and in such
> > case, if there's no MAGIC environent variable set correctly, things
> > do not work. For example, rpmbuild makes use of libmagic and it
> > requries MAGIC to be set correctly.
> >
> > Signed-off-by: Chen Qi 
> > Signed-off-by: Luca Ceresoli 
> > Signed-off-by: Richard Purdie 
> >
> >
> > I would like to ask if anybody else has such an issue. Any propositions 
> > other than reverting commit?
> >
> > 

[yocto] [meta-security][PATCH] *.patch: add Upstream-Status to all patches

[Martin Jansa]

There is new patch-status QA check in oe-core:
https://git.openembedded.org/openembedded-core/commit/?id=76a685bfcf927593eac67157762a53259089ea8a

This is temporary work around just to hide _many_ warnings from
optional patch-status (if you add it to WARN_QA).

This just added
Upstream-Status: Pending
everywhere without actually investigating what's the proper status.

This is just to hide current QA warnings and to catch new .patch files being
added without Upstream-Status, but the number of Pending patches is now 
terrible:

0 (0%)  meta-parsec
N/A (0%)meta-hardening
1 (100%)meta-integrity
15 (68%)meta-tpm
27 (61%)meta-security

Signed-off-by: Martin Jansa 
---
 ...Do-not-get-generation-using-ioctl-when-evm_portable-.patch | 4 
 .../0001-create-tpm-key-support-well-known-key-option.patch   | 2 ++
 .../files/0002-libtpm-support-env-TPM_SRK_PW.patch| 2 ++
 ...tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch | 2 ++
 ...tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch | 2 ++
 .../recipes-tpm1/tpm-tools/files/tpm-tools-extendpcr.patch| 2 ++
 .../openscap/files/0002-openembedded-add-Poky-distro.patch| 2 ++
 recipes-perl/perl/files/libwhisker2.patch | 2 ++
 recipes-scanners/clamav/files/test.patch  | 2 ++
 .../ecryptfs-utils/files/define_musl_sword_type.patch | 2 ++
 recipes-security/isic/files/configure_fix.patch   | 2 ++
 recipes-security/isic/files/isic-0.07-make.patch  | 2 ++
 recipes-security/isic/files/isic-0.07-netinet.patch   | 2 ++
 13 files changed, 28 insertions(+)

diff --git 
a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
 
b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
index 3624576..f0d8975 100644
--- 
a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
+++ 
b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-Do-not-get-generation-using-ioctl-when-evm_portable-.patch
@@ -13,6 +13,8 @@ ioctl is not supported by the filesystem.
 
 Signed-off-by: Stefan Berger 
 ---
+Upstream-Status: Pending
+
  src/evmctl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
@@ -30,6 +32,8 @@ index 6d2bb67..c35a28c 100644
int fd = open(file, 0);
  
 ---
+Upstream-Status: Pending
+
 2.39.2
 
 
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
index bed8b92..e6068af 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0001-create-tpm-key-support-well-known-key-option.patch
@@ -1,3 +1,5 @@
+Upstream-Status: Pending
+
 commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
 Author: Junxian.Xiao 
 Date:   Wed Jun 19 18:57:13 2013 +0800
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
index 2caaaf0..74def4f 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0002-libtpm-support-env-TPM_SRK_PW.patch
@@ -1,3 +1,5 @@
+Upstream-Status: Pending
+
 commit 16dac0cb7b73b8a7088300e45b98ac20819b03ed
 Author: Junxian.Xiao 
 Date:   Wed Jun 19 18:57:13 2013 +0800
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
index cc8772d..732961d 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0003-tpm-openssl-tpm-engine-parse-an-encrypted-tpm-SRK-pa.patch
@@ -17,6 +17,8 @@ export TPM_SRK_ENC_PW=
 
 Signed-off-by: Meng Li 
 ---
+Upstream-Status: Pending
+
  e_tpm.c | 157 +++-
  e_tpm.h |   4 ++
  e_tpm_err.c |   4 ++
diff --git 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
index 535472a..3cbfc3c 100644
--- 
a/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-from-c.patch
+++ 
b/meta-tpm/recipes-tpm1/openssl-tpm-engine/files/0004-tpm-openssl-tpm-engine-change-variable-c-type-fro

Re: [yocto] [meta-selinux][dunfell][PATCH] audit: Add https protocol for clonning repository

[Shubham Kulkarni]

Hi Team,

Is there any update for this patch? Can you pIs let me know, if there's any
issue with the patch.

Thanks,
Shubham

On Wed, Jun 7, 2023 at 12:57 PM Shubham Kulkarni via lists.yoctoproject.org
 wrote:

> From: Shubham Kulkarni 
>
>  audit repository clone failing with git protocol as
>  github.com requires the https protocol to be used
>
> Signed-off-by: Shubham Kulkarni 
> ---
>  recipes-security/audit/audit_2.8.5.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-security/audit/audit_2.8.5.bb
> b/recipes-security/audit/audit_2.8.5.bb
> index af36ed5..e372f66 100644
> --- a/recipes-security/audit/audit_2.8.5.bb
> +++ b/recipes-security/audit/audit_2.8.5.bb
> @@ -7,7 +7,7 @@ SECTION = "base"
>  LICENSE = "GPLv2+ & LGPLv2+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
>
> -SRC_URI = "git://
> github.com/linux-audit/${BPN}-userspace.git;branch=2.8_maintenance
> 
> \
> +SRC_URI = "git://
> github.com/linux-audit/${BPN}-userspace.git;branch=2.8_maintenance;protocol=https
> 
> \
> file://Add-substitue-functions-for-strndupa-rawmemchr.patch \
> file://Fixed-swig-host-contamination-issue.patch \
> file://0001-lib-i386_table.h-add-new-syscall.patch \
> --
> 2.24.4
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60369): https://lists.yoctoproject.org/g/yocto/message/60369
Mute This Topic: https://lists.yoctoproject.org/mt/99380030/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-