"tpm2" is used elsewhere in distro and machine featues to
enable TPM device support.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Without this there is a floating dependency which can fall back
to build host and possibly fail if header file is found but
shared library not. Without this change do_configure log
shows:
checking for efivar... no
checking for efivar/efivar.h... no
../tpm2-tools-5.7/configure: line 15461: efivar: command not found
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Fix the verity class when the IMAGE_BASENAME has changed. Prefer DM_VERITY_IMAGE
for staging env and wic fragment so it matchs what is used in the
dm-verity-image-initramfs and the base wks systemd-bootdisk-dmverity.wks.in.
Signed-off-by: Louis Rannou <louis.rannou@non.se.com>
Signed-off-by: Louis Rannou <louis.rannou@syslinbit.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Useful to pass additional arguments to veritysetup, for example
'--no-superblock' to make system less vulnerable to certain types of
attacks and data maniputaion on the disk.
Signed-off-by: Grygorii Tertychnyi <grembeter@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Measured Boot is the term used to describe the process of securely
recording and computing hashes of code and critical data at each stage
in the boot chain prior to their use.
These measurements can be employed by other system components to
establish a comprehensive attestation system. For example, they could be
employed to enforce local attestation policies (such as the release of
specific platform keys) or to securely transmit them to a remote
challenger, also known as a verifier, post-boot to verify the condition
of the code and critical data.
Measured launch does not authenticate the code or critical data; rather,
it records the code or critical data that was present on the system
during boot.
Initially, the TPM measures the BIOS/EFI layer in the fundamental flow.
This measurement involves the generation of a cryptographic hash of the
binary image and the verification of the binary instructions that this
layer will execute. The TPM stores the generated hash in one of the
numerous "slots" in the Platform Configuration Register (PCR). The TPM
or entities external to the TPM can read these portions of memory at a
later time; however, they are unalterable once they have been written.
These memory pieces are protected by integrity protection from the
instant they are first written. This guarantees that the value written
to a PCR by the TPM will remain constant for the duration of the system,
unless the system is powered off or rebooted.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Javier Tia <javier.tia@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The project uses /usr/bin/python as the path to the python3 interpreter
in the shebang of the python3 script /usr/sbin/sss_obfuscate[1].
OpenEmbedded uses /usr/bin/python3, and thus, it causes bitbake to raise
the QA issue attached below.
This fixes the path to the python3 interpreter by sed'ing the shebang at
do_install if the python3 is set in the PACKAGECONFIG.
Fixes:
NOTE: Executing Tasks
ERROR: sssd-2.9.2-r0 do_package_qa: QA Issue: /usr/sbin/sss_obfuscate contained in package sssd-python requires /usr/bin/python, but no providers found in RDEPENDS:sssd-python? [file-rdeps]
ERROR: sssd-2.9.2-r0 do_package_qa: Fatal QA errors were found, failing task.
[1]: https://github.com/SSSD/sssd/blob/2.5.2/src/tools/sss_obfuscate#L1
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The project installs the python script sss_obfuscate to the /usr/sbin
directory and the modules to the /usr/lib/python3.X directory.
The recipe does not ship the python modules to the package sssd, and
thus, it raises the QA issue attached below.
This adds the python artifacts (sss_obfuscate script and module files)
to the dedicated package sssd-python.
Fixes:
NOTE: Executing Tasks
ERROR: sssd-2.9.2-r0 do_package: QA Issue: sssd: Files/directories were installed but not shipped in any package:
/usr/lib/python3.12/site-packages/pysss.so
/usr/lib/python3.12/site-packages/pyhbac.so
/usr/lib/python3.12/site-packages/pysss_murmur.so
/usr/lib/python3.12/site-packages/pysss_nss_idmap.so
/usr/lib/python3.12/site-packages/SSSDConfig
/usr/lib/python3.12/site-packages/SSSDConfig-2.9.2-py3.12.egg-info
/usr/lib/python3.12/site-packages/SSSDConfig/__init__.py
/usr/lib/python3.12/site-packages/SSSDConfig/ipachangeconf.py
/usr/lib/python3.12/site-packages/SSSDConfig/sssdoptions.py
/usr/lib/python3.12/site-packages/SSSDConfig/__pycache__
/usr/lib/python3.12/site-packages/SSSDConfig/__pycache__/__init__.cpython-312.pyc
/usr/lib/python3.12/site-packages/SSSDConfig/__pycache__/ipachangeconf.cpython-312.pyc
/usr/lib/python3.12/site-packages/SSSDConfig/__pycache__/sssdoptions.cpython-312.pyc
/usr/lib/python3.12/site-packages/SSSDConfig-2.9.2-py3.12.egg-info/dependency_links.txt
/usr/lib/python3.12/site-packages/SSSDConfig-2.9.2-py3.12.egg-info/top_level.txt
/usr/lib/python3.12/site-packages/SSSDConfig-2.9.2-py3.12.egg-info/SOURCES.txt
/usr/lib/python3.12/site-packages/SSSDConfig-2.9.2-py3.12.egg-info/PKG-INFO
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
sssd: 17 installed and not shipped files. [installed-vs-shipped]
ERROR: sssd-2.9.2-r0 do_package: Fatal QA errors were found, failing task.
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The Makefile runs setup.py on the target all-local[1].
The file setup.py uses the deprecated module distutils[2]; sssd-2.10.0
has moved to setuptools[3].
This installs python3-setuptools-native to fix the do_compile issue
below:
Fixes:
| Traceback (most recent call last):
| File "/home/gportay/src/build/tmp/work/core2-64-poky-linux/sssd/2.9.2/build/src/config/setup.py", line 25, in <module>
| from distutils.core import setup
| ModuleNotFoundError: No module named 'distutils'
[1]: https://github.com/SSSD/sssd/blob/2.9.2/Makefile.am#L5462
[2]: https://github.com/SSSD/sssd/blob/2.9.2/src/config/setup.py.in#L25
[3]: 9efd79b010
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The configure script guesses the target system from the host if no
--with-os= is set[1]. It is untrue if cross-compiling.
The guessed host operating system is used then to do specific things
fort target build.
The commit[2] passes the downstream debian option --install-layout=deb
to setup.py[3] if the host system is debian based, and thus, it raises
the error attached below as that debian-specific option[4] is not part
of the openembedded[5] world.
This sets the Fedora operating system thanks to the existing configure
option --with-os=fedora, that is relatively sain operating system for
the needs of openembedded.
Fixes:
| (...)/build/tmp/work/aarch64-poky-linux/sssd/2.5.2-r0/build/src/config/setup.py:25: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
| from distutils.core import setup
| usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
| or: setup.py --help [cmd1 cmd2 ...]
| or: setup.py --help-commands
| or: setup.py cmd --help
|
| error: option --install-layout not recognized
| Traceback (most recent call last):
| File "/home/gportay/src/openembedded-tests/build/tmp/work/core2-64-poky-linux/sssd/2.9.2/build/src/config/setup.py", line 25, in <module>
| from distutils.core import setup
| ModuleNotFoundError: No module named 'distutils'
Note: Upstream has introduced the "unknown" operating systemd with the
upcoming version 2.10.0[6][7]. The change can be backported.
[1]: https://github.com/SSSD/sssd/blob/2.5.2/src/external/platform.m4#L1-L31
[2]: e6ae55d542
[3]: https://github.com/SSSD/sssd/blob/2.5.2/Makefile.am#L32-L35
[4]: https://sources.debian.org/patches/setuptools/68.1.2-2/install-layout.diff/#L7
[5]: https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb?h=kirkstone
[6]: 7b32dc0ab8
[7]: https://github.com/SSSD/sssd/pull/7398
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The configure script checks for the utility python3.X-config to be in
$PATH; that script is shipped by the package python3-native.
The recipe does not depend on the package python3-native which causes
the task do_configure to fail.
The recipe inherits from the bbclass python3-dir that does not install
the required script to the sysroot. The bbclass python3native inherits
from (the already inherited bbclass) python3-dir and it adds the missing
dependency to python3-native.
This fixes the configure error by "upgrading" the inherit bbclass from
python3-dir to python3-native.
Fixes:
| checking for python3.12-config... no
| configure: error:
| The program python3.12-config was not found in search path.
| Please ensure that it is installed and its directory is included in the search
| path. If you want to build sssd without python3 bindings then specify
| --without-python3-bindings when running configure.
| NOTE: The following config.log files may provide further information.
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The variable HAVE_PYTHON3 expects a boolean value[1] and the configure
script raises an error if the option --with-python3-bindings is set and
if the value HAVE_PYTHON3 is not "yes"[2].
The recipe sets a non-boolean value to ac_cv_prog_HAVE_PYTHON3 and thus
causes the task do_configure to fail.
This fixes the value set to ac_cv_prog_HAVE_PYTHON3 by setting it to yes
instead of $(PYTHON_DIR).
Fixes:
| checking for python3... (cached) python3.12
| configure: error:
| The program python3 was not found in search path.
| Please ensure that it is installed and its directory is included in the search
| path. It is required for building python3 bindings. If you do not want to build
| them please use argument --without-python3-bindings when running configure.
| NOTE: The following config.log files may provide further information.
[1]: https://github.com/SSSD/sssd/blob/2.5.2/configure.ac#L323-L325
[2]: https://github.com/SSSD/sssd/blob/2.5.2/configure.ac#L353-L377
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
SSSD has introduced the internal tool sss_analyze since 2.6.0[1].
Add log parsing tool which can be used to track requests across
responder and backend logs.
sss_analyze is a python3 script[2] with modules[3] that is run by the
sssctl command analyze[4][5][6].
The autotools installs the files to ${libexec} and ${python3dir}[7]. The
latter is set if the configure option --with-python3-bindings is set
only.
As a consequence, the Makefile installs the python3 files to /sssd
instead of /usr/lib/python3.12/site-packages/sssd if the option
--with-python3-bindings is unset:
gportay@archlinux ~/src $ find build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/modules
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/modules/__init__.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/modules/request.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/modules/error.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/__init__.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/source_files.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/source_journald.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/source_reader.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/parser.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/sss_analyze.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/sssd/util.py
The sss_analyze tool is unrelated to the python3 bindings; the sssctl
does not condition its code if the python3 bindings are unset.
Therefore, sss_analyze has to be installed even if the python3 bindings
are unset.
This ensures the variable python3dir is set to the expected location by
adding it to --without-python3-bindings if the python3 feature is
disabled.
gportay@archlinux ~/src $ find build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/modules
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/modules/__init__.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/modules/request.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/modules/error.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/__init__.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/source_files.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/source_journald.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/source_reader.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/parser.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/sss_analyze.py
build/tmp/work/core2-64-poky-linux/sssd/2.9.2/image/usr/lib/python3.12/site-packages/sssd/util.py
[1]: 82e051e1f1
[2]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/analyzer/sss_analyze#L1
[3]: https://github.com/SSSD/sssd/tree/2.9.2/src/tools/analyzer
[4]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/sssctl/sssctl_logs.c#L47
[5]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/sssctl/sssctl_logs.c#L605
[6]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/sssctl/sssctl.c#L337
[7]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/analyzer/Makefile.am#L7
[8]: https://github.com/SSSD/sssd/blob/2.9.2/configure.ac#L394
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The internal tool sss_analyze is a python script run by the sssctl
command analyze.
The script sss_analyze imports the python module logging[1].
However, the package sssd lacks installing this python module that is
required to run the script.
This adds the missing run-time dependency python3-logging to ensure this
module comes along the package sssd.
Fixes:
root@qemux86-64:~# sssctl analyze
Traceback (most recent call last):
File "/usr/libexec/sssd/sss_analyze", line 3, in <module>
from sssd import sss_analyze
File "/usr/lib/python3.12/site-packages/sssd/sss_analyze.py", line 3, in <module>
from sssd.modules import request
File "/usr/lib/python3.12/site-packages/sssd/modules/request.py", line 2, in <module>
import logging
ModuleNotFoundError: No module named 'logging'
[1]: https://github.com/SSSD/sssd/blob/2.9.2/src/tools/analyzer/source_files.py#L2
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The internal tool sss_analyze is a python script run by the sssctl
command analyze.
The script sss_analyze is shipped by the package sssd since 2.6.0.
However, the package sssd lacks installing the python interpreter that
is required to run the script.
This adds the missing run-time dependency python3-core to ensure the
interpreter python3 comes along the package sssd.
Fixes:
root@qemux86-64:~# sssctl analyze
env: can't execute 'python3': No such file or directory
Command '/usr/libexec/sssd/sss_analyze' failed with [127]
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Otherwise Makefile isn't regenerated and do_compile fails with:
suricata/7.0.0/suricata-7.0.0/missing: line 81: aclocal-1.16: command not found
after automake upgrade from 1.16.5 to 1.17 from:
https://git.openembedded.org/openembedded-core/commit/?id=b98328a6ff07119e7ba4f1072090d789e69edef8
Fixes:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash 'TOPDIR/BUILD/work/mach-distro-linux/suricata/7.0.0/suricata-7.0.0/missing' aclocal-1.16 -I m4
TOPDIR/BUILD/work/mach-distro-linux/suricata/7.0.0/suricata-7.0.0/missing: line 81: aclocal-1.16: command not found
WARNING: 'aclocal-1.16' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<https://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<https://www.gnu.org/software/autoconf>
<https://www.gnu.org/software/m4/>
<https://www.perl.org/>
make: *** [Makefile:465: aclocal.m4] Error 127
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The 0.8 orig.tar.gz is not in debian mirror any more. In fact, we
really should avoid using orig.tar.gz like this because distros
like debian will just delete those that they don't maintain any more.
Switch to use git source.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
address new configure error.
Enable pthread always
mhash is being dropped in the next release so switch to gcrypt for now.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Current 1.0.2 version does not work with scarthgap or later releases,
as the asynchat module has been removed (as scheduled) from python's
stdlib as of v3.12.
fail2ban 1.1.0 also does not work out-of-the-box, as the distutils
module which the pyinotify and systemd backends depend has also been
removed.
So update the recipe to point at commit ac62658c10f4, which fixes
those two backends to no longer depend on distutils.
Upstream's out-of-the-box ban action now uses the 'nft'
command. People can still override and customize that in
jail.conf/jail.local, but to make the recipe useful without
customizing things back to use iptables, change the dependency
iptables->nftables.
Since 1.1.0, fail2ban has been python3-only, so the recipe becomes
somewhat simpler since the whole do_compile preparation step can be
removed.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
