2018-02-02 16:56:11 +01:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# tpm2-tss
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2021-10-05 07:20:16 +02:00
|
|
|
TPM2_TSS_VERSION = 3.1.0
|
2018-02-02 16:56:11 +01:00
|
|
|
TPM2_TSS_SITE = https://github.com/tpm2-software/tpm2-tss/releases/download/$(TPM2_TSS_VERSION)
|
|
|
|
|
TPM2_TSS_LICENSE = BSD-2-Clause
|
|
|
|
|
TPM2_TSS_LICENSE_FILES = LICENSE
|
2021-05-16 19:11:01 +02:00
|
|
|
TPM2_TSS_CPE_ID_VENDOR = tpm2_software_stack_project
|
|
|
|
|
TPM2_TSS_CPE_ID_PRODUCT = tpm2_software_stack
|
2018-02-02 16:56:11 +01:00
|
|
|
TPM2_TSS_INSTALL_STAGING = YES
|
2018-11-16 03:52:15 +01:00
|
|
|
TPM2_TSS_DEPENDENCIES = liburiparser openssl host-pkgconf
|
package/tpm2-tss: fix build on host without setfacl
Fixes:
http://autobuild.buildroot.org/results/eab44622f8d8ff4fbf464b5a98856382f019c2cb/
Since the bump to 3.1.0 in commit 470e2e9bc521 (package/tpm2-tss: bump
version to 3.1.0), the install is borked because it is looking for
programs at configure time, so it finds those on the host if they exist,
or do not find any at all, which can very well differ from what will be
present on the target.
But this is not totally unreasonable: there is no way, at cross-configure
time, for a package to find the tools that will be present at runtime.
All that can be done in such a case is to force the path to such tools.
However, in this case, tpm2-tss only uses setfacl if systemd-tmpfiles is
not available. If the call to setfacl fails, the install does not fail
(split on two lines for readability):
@-$(call make_fapi_dirs) && $(call set_fapi_permissions) \
|| echo "WARNING Failed to create the FAPI directories with the correct permissions"
set_fapi_permissions is a macro that eventually expands to:
(chown -R tss:tss "$1") && \
(chmod -R 2775 "$1") && \
(setfacl -m default:group:tss:rwx "$1")
So the call to setfacl will not even be ever attempted, because the
chown will fail first. Furthermore, it would look for the 'tss' username
and groupname from the host, which could differ from those on the
target.
So we can just fake the fact that setfacl is available.
As for the permissions, they are to be set on a directory that is in
${runstatedir}, i.e. /run, which is a tmpfs, so there is no way we can
prepare them at build time. We'd need a startup script or systemd unit,
or proper systemd-tmpfiles support, either of which can be done in a
followup patch by an interested party...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Yair Ben-Avraham <yairba@protonmail.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-11-06 16:45:25 +01:00
|
|
|
|
2019-12-23 12:13:21 +01:00
|
|
|
# 0001-configure-Only-use-CXX-when-fuzzing.patch
|
|
|
|
|
TPM2_TSS_AUTORECONF = YES
|
2018-03-22 21:27:48 +01:00
|
|
|
|
package/tpm2-tss: override auto-detection of groupadd and systemd
tpm2-tss is looking for systemd_sysusers and systemd_tmpfiles, but those
two are not mandatory. However, it might find those from the host.
But that is not an issue in the end, because they are only used to
instanciate the users and create the tmpfiles. At build time on the
host, we do not need them, and on the target, if systemd is being used,
then they will be instanciated/created at boot.
If they are not found, then the fallback paths are taken, and those
fallback paths are those using the setfacl and groupadd and useradd
tools, which we already know are going to fail but that we do not care.
So, we can safely force those two to =no to avoid the install trying to
use the system-wide tools, or even the ones we build as part of
host-systemd ourselves.
Eventually, when systemd-tmpfiles of systemd-sysusers are missing, the
fallback paths use useradd, and configure unconditionally checks for
it, so as for groupadd and setfacl in commits d9123dd79956
(package/tpm2-tss: fix build on host without setfacl) and c8f847c4f4dd
(package/tpm2-tss: fix build on host without groupadd), we just fake the
detection of groupadd.
Fixes:
- http://autobuild.buildroot.org/results//97bfa8f7dcb12e36bd63c9d06fb39418070d840b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-11-09 08:10:01 +01:00
|
|
|
# systemd-sysusers and systemd-tmpfiles are only used at install time
|
|
|
|
|
# to trigger the creation of users adn tmpfiles, which we do not care
|
|
|
|
|
# about at build time. groupadd, useradd, and setfacl are used in the
|
|
|
|
|
# fallback path when systemd-sysusers or systemd-tmpfiles are missing
|
|
|
|
|
# and their failure is ignored anyway.
|
package/tpm2-tss: fix build on host without setfacl
Fixes:
http://autobuild.buildroot.org/results/eab44622f8d8ff4fbf464b5a98856382f019c2cb/
Since the bump to 3.1.0 in commit 470e2e9bc521 (package/tpm2-tss: bump
version to 3.1.0), the install is borked because it is looking for
programs at configure time, so it finds those on the host if they exist,
or do not find any at all, which can very well differ from what will be
present on the target.
But this is not totally unreasonable: there is no way, at cross-configure
time, for a package to find the tools that will be present at runtime.
All that can be done in such a case is to force the path to such tools.
However, in this case, tpm2-tss only uses setfacl if systemd-tmpfiles is
not available. If the call to setfacl fails, the install does not fail
(split on two lines for readability):
@-$(call make_fapi_dirs) && $(call set_fapi_permissions) \
|| echo "WARNING Failed to create the FAPI directories with the correct permissions"
set_fapi_permissions is a macro that eventually expands to:
(chown -R tss:tss "$1") && \
(chmod -R 2775 "$1") && \
(setfacl -m default:group:tss:rwx "$1")
So the call to setfacl will not even be ever attempted, because the
chown will fail first. Furthermore, it would look for the 'tss' username
and groupname from the host, which could differ from those on the
target.
So we can just fake the fact that setfacl is available.
As for the permissions, they are to be set on a directory that is in
${runstatedir}, i.e. /run, which is a tmpfs, so there is no way we can
prepare them at build time. We'd need a startup script or systemd unit,
or proper systemd-tmpfiles support, either of which can be done in a
followup patch by an interested party...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Yair Ben-Avraham <yairba@protonmail.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-11-06 16:45:25 +01:00
|
|
|
TPM2_TSS_CONF_OPTS = \
|
2021-11-07 18:37:49 +01:00
|
|
|
ac_cv_prog_result_groupadd=yes \
|
package/tpm2-tss: fix build on host without setfacl
Fixes:
http://autobuild.buildroot.org/results/eab44622f8d8ff4fbf464b5a98856382f019c2cb/
Since the bump to 3.1.0 in commit 470e2e9bc521 (package/tpm2-tss: bump
version to 3.1.0), the install is borked because it is looking for
programs at configure time, so it finds those on the host if they exist,
or do not find any at all, which can very well differ from what will be
present on the target.
But this is not totally unreasonable: there is no way, at cross-configure
time, for a package to find the tools that will be present at runtime.
All that can be done in such a case is to force the path to such tools.
However, in this case, tpm2-tss only uses setfacl if systemd-tmpfiles is
not available. If the call to setfacl fails, the install does not fail
(split on two lines for readability):
@-$(call make_fapi_dirs) && $(call set_fapi_permissions) \
|| echo "WARNING Failed to create the FAPI directories with the correct permissions"
set_fapi_permissions is a macro that eventually expands to:
(chown -R tss:tss "$1") && \
(chmod -R 2775 "$1") && \
(setfacl -m default:group:tss:rwx "$1")
So the call to setfacl will not even be ever attempted, because the
chown will fail first. Furthermore, it would look for the 'tss' username
and groupname from the host, which could differ from those on the
target.
So we can just fake the fact that setfacl is available.
As for the permissions, they are to be set on a directory that is in
${runstatedir}, i.e. /run, which is a tmpfs, so there is no way we can
prepare them at build time. We'd need a startup script or systemd unit,
or proper systemd-tmpfiles support, either of which can be done in a
followup patch by an interested party...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Yair Ben-Avraham <yairba@protonmail.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-11-06 16:45:25 +01:00
|
|
|
ac_cv_prog_result_setfacl=yes \
|
package/tpm2-tss: override auto-detection of groupadd and systemd
tpm2-tss is looking for systemd_sysusers and systemd_tmpfiles, but those
two are not mandatory. However, it might find those from the host.
But that is not an issue in the end, because they are only used to
instanciate the users and create the tmpfiles. At build time on the
host, we do not need them, and on the target, if systemd is being used,
then they will be instanciated/created at boot.
If they are not found, then the fallback paths are taken, and those
fallback paths are those using the setfacl and groupadd and useradd
tools, which we already know are going to fail but that we do not care.
So, we can safely force those two to =no to avoid the install trying to
use the system-wide tools, or even the ones we build as part of
host-systemd ourselves.
Eventually, when systemd-tmpfiles of systemd-sysusers are missing, the
fallback paths use useradd, and configure unconditionally checks for
it, so as for groupadd and setfacl in commits d9123dd79956
(package/tpm2-tss: fix build on host without setfacl) and c8f847c4f4dd
(package/tpm2-tss: fix build on host without groupadd), we just fake the
detection of groupadd.
Fixes:
- http://autobuild.buildroot.org/results//97bfa8f7dcb12e36bd63c9d06fb39418070d840b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-11-09 08:10:01 +01:00
|
|
|
ac_cv_prog_systemd_sysusers=no \
|
|
|
|
|
ac_cv_prog_systemd_tmpfiles=no \
|
|
|
|
|
ac_cv_prog_result_useradd=yes \
|
package/tpm2-tss: fix build on host without setfacl
Fixes:
http://autobuild.buildroot.org/results/eab44622f8d8ff4fbf464b5a98856382f019c2cb/
Since the bump to 3.1.0 in commit 470e2e9bc521 (package/tpm2-tss: bump
version to 3.1.0), the install is borked because it is looking for
programs at configure time, so it finds those on the host if they exist,
or do not find any at all, which can very well differ from what will be
present on the target.
But this is not totally unreasonable: there is no way, at cross-configure
time, for a package to find the tools that will be present at runtime.
All that can be done in such a case is to force the path to such tools.
However, in this case, tpm2-tss only uses setfacl if systemd-tmpfiles is
not available. If the call to setfacl fails, the install does not fail
(split on two lines for readability):
@-$(call make_fapi_dirs) && $(call set_fapi_permissions) \
|| echo "WARNING Failed to create the FAPI directories with the correct permissions"
set_fapi_permissions is a macro that eventually expands to:
(chown -R tss:tss "$1") && \
(chmod -R 2775 "$1") && \
(setfacl -m default:group:tss:rwx "$1")
So the call to setfacl will not even be ever attempted, because the
chown will fail first. Furthermore, it would look for the 'tss' username
and groupname from the host, which could differ from those on the
target.
So we can just fake the fact that setfacl is available.
As for the permissions, they are to be set on a directory that is in
${runstatedir}, i.e. /run, which is a tmpfs, so there is no way we can
prepare them at build time. We'd need a startup script or systemd unit,
or proper systemd-tmpfiles support, either of which can be done in a
followup patch by an interested party...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Yair Ben-Avraham <yairba@protonmail.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-11-06 16:45:25 +01:00
|
|
|
--with-crypto=ossl \
|
|
|
|
|
--disable-doxygen-doc \
|
|
|
|
|
--disable-defaultflags
|
|
|
|
|
|
2019-12-15 00:25:59 +01:00
|
|
|
# uses C99 code but forgets to pass -std=c99 when --disable-defaultflags is used
|
|
|
|
|
TPM2_TSS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -std=c99"
|
2018-11-19 03:26:24 +01:00
|
|
|
|
2020-10-15 11:00:13 +02:00
|
|
|
ifeq ($(BR2_PACKAGE_TPM2_TSS_FAPI),y)
|
|
|
|
|
TPM2_TSS_DEPENDENCIES += json-c libcurl
|
|
|
|
|
TPM2_TSS_CONF_OPTS += --enable-fapi
|
|
|
|
|
else
|
|
|
|
|
TPM2_TSS_CONF_OPTS += --disable-fapi
|
|
|
|
|
endif
|
2020-02-20 22:45:30 +01:00
|
|
|
|
2018-02-02 16:56:11 +01:00
|
|
|
$(eval $(autotools-package))
|
