Date   

gpsd [version 3.23; master branch]: Is it possible to include / enable ubxtool?

Matthias Klein
 

Hello,

is it somehow possible to add the ubxtool in the gpsd-utils package?

(I use the current master branch)

Best regards,
Matthias


Re: editing Makefile after configure stage to disable -Werror

Khem Raj
 

On 8/31/21 12:52 AM, Ivan Riabtsov wrote:
i cleaned out -Werror wherever possible with command:
sed -i 's/-Werror//g' $(find . -type f -exec egrep -l _no_Werror {} \;)
and elfutils is builded
Please try backporting this fix

https://sourceware.org/git/?p=elfutils.git;a=commit;h=a01938d584b91e747167bb4b3f30ec300c4d6e43

if this is not enough then I think you just need to edit config/eu.am to remove -Werror and perhaps thats enough, but upstream elfutils is generally receptive to
Werror issues, so I would also suggest that in parallel you report it
upstream as well.

вт, 31 авг. 2021 г. в 09:41, Ivan Riabtsov via lists.yoctoproject.org
<ivriabtsov=gmail.com@...>:

Hello, I have the following error:

../../elfutils-0.166/libelf/libelfP.h:53:30: error: ‘__elf64_msize’
specifies less restrictive attribute than its target ‘elf64_fsize’:
‘const’ [-Werror=missing-attributes]

i try to solve this by patch:

diff -Naur elfutils-0.166_orig/libelf/libelfP.h elfutils-0.166/libelf/libelfP.h
--- elfutils-0.166_orig/libelf/libelfP.h 2016-01-12 15:49:19.000000000 +0300
+++ elfutils-0.166/libelf/libelfP.h 2021-08-30 19:38:44.866175082 +0300
@@ -48,6 +48,8 @@


/* Helper Macros to write 32 bit and 64 bit functions. */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmissing-attributes"
#define __elfw2_(Bits, Name) __elf##Bits##_##Name
#define elfw2_(Bits, Name) elf##Bits##_##Name
#define ElfW2_(Bits, Name) Elf##Bits##_##Name
@@ -632,4 +634,5 @@
#define INVALID_NDX(ndx, type, data) \
unlikely ((data)->d_size / sizeof (type) <= (unsigned int) (ndx))

+#pragma GCC diagnostic pop
#endif /* libelfP.h */


But the patch does not work, error appears again.


i try to add --disable-werror to configure flags, but i have follows warning:

configure: WARNING: unrecognized options: --disable-werror.


The only solution to the problem I could think of is editing the
Makefile after configuration, please tell me how this can be done?






Re: Binary compliance validation

Anatol Belski
 

Hi,

On 8/31/2021 5:58 PM, Bruce Ashfield wrote:
On Tue, Aug 31, 2021 at 11:48 AM Anatol Belski
<anbelski@...> wrote:
Hi,

I'm writing to present an ABI compliance check mechanism for Poky
recently developed to help improve the product stability. It is still
an early work which however has already proven itself useful and thus
the time seems right to ask for the community view.

Binary compliance is an important metric, when a distrubition intends
to provide stability guarantees to consumers outside the monolithic
image build. For example, projects utilizing the SDK might not be in
sync with the image builds from even the same branch. Even in stable
branches where bugfixes, security patches or even non breaching
upgrades have to flow in as necessary, there's is currently no
verifiable mechainsm to ensure the binary compatibility long term.

The currently implemented validation is based on libabigail and as such
is focused on the ABI compliance. Libabigail is a tool developed by Red
Hat and is in use for Fedora and RHEL RPM builds. Some companies are
known to utilize libabigail to support the kernel maintanance (Linux
kernel for Android). The meta layer contains a bbclass extending the
buildhistory functionality with the ABI serialization and comparison.
One buildhistory version taken as a baseline would serve the comparison
with any follow up builds. The ABI changes detected are then reported.

The handling routines in Poky are currently attached to the install
task, which implies the baseline build needs to take place with the
sstate disabled. The follow up buids can use sstate and in that case
the postinstall routines will be invoked only if some change took place
and thus do_install has been called.

The implementation is made as a core Python module, which can be used
in a Yocto layer or imported in any other script. The layer is
available under:
https://github.com/clio-project/meta-binaryaudit

and the accompanying python module (which moves at some faster pace and
is synchronized into the layer) and a command line tool:
https://github.com/clio-project/python-binaryaudit

The layer is yet an early work and the impluementation doesn't exhaust
all the possible features of Poky and libabigail. However, it already
proves itself helpful and is used for some real products to esure the
ABI stability. Certainly the mechanisms and the integration can be
improved.

The future for this layer is open containing at least the topics below:

- Binary size auditing.
- Security auditing.

As a shorter term serviceableness, the ABI compliance validation
mechanism seems to be a useful tool in helping to keep promises on LTS,
but would most likely also help maintaining non LTS branches. It would
be great to receive any feedback, reviews and ideas in regard to meta-
binaryaudit.
Out of curiosity, are you coordinating with the work sent in March by BMW ?

see the email with the subject: [yocto] Demo of abi checker hook with hashequiv

And the associated layers: https://github.com/bmwcarit/meta-abicompat
and https://github.com/bmwcarit/meta-abicompat-poky

Thanks for the pointer! Nope, there's no coordination, it's a separate effort and seems the approach and goals are somewhat different. The sstate handling is however a very interesting approach. One could check if these works can be merged together, if there's an interest.

Regards

Anatol

Bruce

Thanks!

Anatol





--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Re: Binary compliance validation

Bruce Ashfield
 

On Tue, Aug 31, 2021 at 11:48 AM Anatol Belski
<anbelski@...> wrote:

Hi,

I'm writing to present an ABI compliance check mechanism for Poky
recently developed to help improve the product stability. It is still
an early work which however has already proven itself useful and thus
the time seems right to ask for the community view.

Binary compliance is an important metric, when a distrubition intends
to provide stability guarantees to consumers outside the monolithic
image build. For example, projects utilizing the SDK might not be in
sync with the image builds from even the same branch. Even in stable
branches where bugfixes, security patches or even non breaching
upgrades have to flow in as necessary, there's is currently no
verifiable mechainsm to ensure the binary compatibility long term.

The currently implemented validation is based on libabigail and as such
is focused on the ABI compliance. Libabigail is a tool developed by Red
Hat and is in use for Fedora and RHEL RPM builds. Some companies are
known to utilize libabigail to support the kernel maintanance (Linux
kernel for Android). The meta layer contains a bbclass extending the
buildhistory functionality with the ABI serialization and comparison.
One buildhistory version taken as a baseline would serve the comparison
with any follow up builds. The ABI changes detected are then reported.

The handling routines in Poky are currently attached to the install
task, which implies the baseline build needs to take place with the
sstate disabled. The follow up buids can use sstate and in that case
the postinstall routines will be invoked only if some change took place
and thus do_install has been called.

The implementation is made as a core Python module, which can be used
in a Yocto layer or imported in any other script. The layer is
available under:
https://github.com/clio-project/meta-binaryaudit

and the accompanying python module (which moves at some faster pace and
is synchronized into the layer) and a command line tool:
https://github.com/clio-project/python-binaryaudit

The layer is yet an early work and the impluementation doesn't exhaust
all the possible features of Poky and libabigail. However, it already
proves itself helpful and is used for some real products to esure the
ABI stability. Certainly the mechanisms and the integration can be
improved.

The future for this layer is open containing at least the topics below:

- Binary size auditing.
- Security auditing.

As a shorter term serviceableness, the ABI compliance validation
mechanism seems to be a useful tool in helping to keep promises on LTS,
but would most likely also help maintaining non LTS branches. It would
be great to receive any feedback, reviews and ideas in regard to meta-
binaryaudit.
Out of curiosity, are you coordinating with the work sent in March by BMW ?

see the email with the subject: [yocto] Demo of abi checker hook with hashequiv

And the associated layers: https://github.com/bmwcarit/meta-abicompat
and https://github.com/bmwcarit/meta-abicompat-poky

Bruce


Thanks!

Anatol




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Binary compliance validation

Anatol Belski
 

Hi,

I'm writing to present an ABI compliance check mechanism for Poky
recently developed to help improve the product stability. It is still
an early work which however has already proven itself useful and thus
the time seems right to ask for the community view.

Binary compliance is an important metric, when a distrubition intends
to provide stability guarantees to consumers outside the monolithic
image build. For example, projects utilizing the SDK might not be in
sync with the image builds from even the same branch. Even in stable
branches where bugfixes, security patches or even non breaching
upgrades have to flow in as necessary, there's is currently no
verifiable mechainsm to ensure the binary compatibility long term.

The currently implemented validation is based on libabigail and as such
is focused on the ABI compliance. Libabigail is a tool developed by Red
Hat and is in use for Fedora and RHEL RPM builds. Some companies are
known to utilize libabigail to support the kernel maintanance (Linux
kernel for Android). The meta layer contains a bbclass extending the
buildhistory functionality with the ABI serialization and comparison.
One buildhistory version taken as a baseline would serve the comparison
with any follow up builds. The ABI changes detected are then reported.

The handling routines in Poky are currently attached to the install
task, which implies the baseline build needs to take place with the
sstate disabled. The follow up buids can use sstate and in that case
the postinstall routines will be invoked only if some change took place
and thus do_install has been called.

The implementation is made as a core Python module, which can be used
in a Yocto layer or imported in any other script. The layer is
available under:
https://github.com/clio-project/meta-binaryaudit

and the accompanying python module (which moves at some faster pace and
is synchronized into the layer) and a command line tool:
https://github.com/clio-project/python-binaryaudit

The layer is yet an early work and the impluementation doesn't exhaust
all the possible features of Poky and libabigail. However, it already
proves itself helpful and is used for some real products to esure the
ABI stability. Certainly the mechanisms and the integration can be
improved.

The future for this layer is open containing at least the topics below:

- Binary size auditing.
- Security auditing.

As a shorter term serviceableness, the ABI compliance validation
mechanism seems to be a useful tool in helping to keep promises on LTS,
but would most likely also help maintaining non LTS branches. It would
be great to receive any feedback, reviews and ideas in regard to meta-
binaryaudit.

Thanks!

Anatol


Yocto Project Status WW35`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M3 (Feature Freeze)

Next Deadline: 23rd Aug. 2021 YP 3.4 M3 build (Feature Freeze)

 

Next Team Meetings:

 

Key Status/Updates:

  • We are now at feature freeze for YP 3.4
  • Rust was merged into core, it was touch and go whether we could/would or not. Unfortunately there was an error found after merging with cargo-native on centos7 hosts which we still need to resolve before building M3.
  • Fixes for glibc 2.34 and pseudo were merged however this uses a binary shim and isn’t an ideal way to solve the issues. We need to find a way to have active development on pseudo with investigation into possible replacement approaches.
  • A kernel issue introduced in recent kernel module versioning changes needs to resolved before we can build M3.
  • The glibc 2.34 upgrade caused issues with docker and the clone3 syscall returning EPERM instead of ENOSYS. We will likely have to add a workaround to our glibc until released versions of docker have the upstream fix.
  • Intermittent issues are ongoing and help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: extrausers-bbclass: plaintext password (since shadow update to 4.9)

Matthias Klein
 

Hello Peter,

thanks for the solution!

Many greetings,
Matthias

-----Ursprüngliche Nachricht-----
Von: Peter Bergin <peter@...>
Gesendet: Dienstag, 31. August 2021 09:45
An: Matthias Klein <matthias.klein@...>; yocto@...
Betreff: Re: [yocto] extrausers-bbclass: plaintext password (since shadow update to 4.9)

Hi Matthias,

On 2021-08-31 09:03, Matthias Klein wrote:
But I have not found a way to set the password with EXTRA_USERS_PARAMS.
Do you know a working variant?
Is it a requirement that you need to regenerate the hash on every build?
If not one solution can be:

    inherit extrausers

    #
    # HASH generated with this command:
    # python3 -c "import crypt; print(crypt.crypt('toor', crypt.METHOD_SHA512))"
    #
    HASH =
"\\\$6\\\$8Z5vMcqCIB19PgY8\\\$Sv4kAfsH1k.SANHL5JVb6hdqmQWHOeH0Rjrjyii7fGAK20Gclj/.qiBvUPnAfh.WSsr1.XV0pUNom2L9oYYDV/"

    EXTRA_USERS_PARAMS = " \
       usermod -p ${HASH} root; \
    "

Best regards,
/Peter


Re: editing Makefile after configure stage to disable -Werror

Markus Volk
 

you could try to add a line like this to your recipe:

CFLAGS:append = " -Wno-error=missing-attributes"


Am 31.08.21 um 08:41 schrieb Ivan Riabtsov:

Hello, I have the following error:

../../elfutils-0.166/libelf/libelfP.h:53:30: error: ‘__elf64_msize’
specifies less restrictive attribute than its target ‘elf64_fsize’:
‘const’ [-Werror=missing-attributes]

i try to solve this by patch:

diff -Naur elfutils-0.166_orig/libelf/libelfP.h elfutils-0.166/libelf/libelfP.h
--- elfutils-0.166_orig/libelf/libelfP.h 2016-01-12 15:49:19.000000000 +0300
+++ elfutils-0.166/libelf/libelfP.h 2021-08-30 19:38:44.866175082 +0300
@@ -48,6 +48,8 @@


 /* Helper Macros to write 32 bit and 64 bit functions.  */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmissing-attributes"
 #define __elfw2_(Bits, Name) __elf##Bits##_##Name
 #define elfw2_(Bits, Name) elf##Bits##_##Name
 #define ElfW2_(Bits, Name) Elf##Bits##_##Name
@@ -632,4 +634,5 @@
 #define INVALID_NDX(ndx, type, data) \
   unlikely ((data)->d_size / sizeof (type) <= (unsigned int) (ndx))

+#pragma GCC diagnostic pop
 #endif  /* libelfP.h */


But the patch does  not work, error appears again.


i try to add --disable-werror to configure flags, but i have follows warning:

configure: WARNING: unrecognized options: --disable-werror.


The only solution to the problem I could think of is editing the
Makefile after configuration, please tell me how this can be done?




Re: downgrade openssl libraryes

Bas Mevissen
 

On 2021-08-30 16:56, Ivan Riabtsov wrote:
I have phytec imx6ul board with a preinstalled os. On this os opessl
version is 1.0.2j i need to build nginx for this board, but i can't
build yocto same version as i have on board, so I grabbed a newer
version of yocto from phytec site, rolled back glibc and try to roll
back openssl. I do not want to flash the device, as I'm afraid to get
brick
Why are you afraid to brick the device? You can use mfgtool to reflash the device from scratch, including u-boot. It works with a special boot mode pin setting and uses an USB port. Depending on the board, one might need to buy or create a custom cable.

Bas.

пн, 30 авг. 2021 г. в 16:51, Alexander Kanavin <alex.kanavin@...>:
openssl 1.0.2 went out of support at the end of 2019 and you should not be using it. What is the problem you need to solve?
Alex
On Mon, 30 Aug 2021 at 15:33, Ivan Riabtsov <ivriabtsov@...> wrote:
hello i am trying to rollback openssl version from 1.1.1i to 1.0.2j.
Copied the recipe openssl_1.1.1i.bb to openssl_1.0.2j.bb, saved the
openssl_1.1.1i.bb version with the name openssl_1.1.1i.bb.backup
Отредактировал новый файл, вот разница в файлах:
diff -Nau ./openssl_1.1.1i.bb.backup ./openssl_1.0.2j.bb
--- ./openssl_1.1.1i.bb.backup 2021-08-27 14:46:07.085808702 +0300
+++ ./openssl_1.0.2j.bb 2021-08-27 16:12:14.216430734 +0300
@@ -7,23 +7,19 @@
# "openssl" here actually means both OpenSSL and SSLeay licenses apply
# (see meta/files/common-licenses/OpenSSL to which "openssl" is
SPDXLICENSEMAPped)
LICENSE = "openssl"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"
DEPENDS = "hostperl-runtime-native"
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
- file://0001-skip-test_symbol_presence.patch \
- file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch
\
- file://afalg.patch \
- file://reproducible.patch \
"
SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
-SRC_URI[sha256sum] =
"e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242"
+SRC_URI[sha256sum] =
"e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
@@ -122,7 +118,7 @@
# WARNING: do not set compiler/linker flags (-I/-D etc.) in
EXTRA_OECONF, as they will fully replace the
# environment variables set by bitbake. Adjust the environment
variables instead.
HASHBANGPERL="/usr/bin/env perl" PERL=perl
PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
- perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS}
--prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir}
$target
+ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS}
--prefix=$useprefix --openssldir=${libdir}/ssl-1.0 --libdir=${libdir}
$target
perl ${B}/configdata.pm --dump
}
@@ -134,30 +130,30 @@
# Create SSL structure for packages such as ca-certificates which
# contain hard-coded paths to /etc/ssl. Debian does the same.
install -d ${D}${sysconfdir}/ssl
- mv ${D}${libdir}/ssl-1.1/certs \
- ${D}${libdir}/ssl-1.1/private \
- ${D}${libdir}/ssl-1.1/openssl.cnf \
+ mv ${D}${libdir}/ssl-1.0/certs \
+ ${D}${libdir}/ssl-1.0/private \
+ ${D}${libdir}/ssl-1.0/openssl.cnf \
${D}${sysconfdir}/ssl/
# Although absolute symlinks would be OK for the target, they become
# invalid if native or nativesdk are relocated from sstate.
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.1/certs
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.1/private
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.1/openssl.cnf
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.0/certs
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.0/private
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.0/openssl.cnf
}
do_install_append_class-native () {
create_wrapper ${D}${bindir}/openssl \
- OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
- SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
- SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
- OPENSSL_ENGINES=${libdir}/engines-1.1
+ OPENSSL_CONF=${libdir}/ssl-1.0/openssl.cnf \
+ SSL_CERT_DIR=${libdir}/ssl-1.0/certs \
+ SSL_CERT_FILE=${libdir}/ssl-1.0/cert.pem \
+ OPENSSL_ENGINES=${libdir}/engines-1.0
}
do_install_append_class-nativesdk () {
mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
install -m 644 ${WORKDIR}/environment.d-openssl.sh
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
- sed 's|/usr/lib/ssl/|/usr/lib/ssl-1.1/|g' -i
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
+ sed 's|/usr/lib/ssl/|/usr/lib/ssl-1.0/|g' -i
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
}
PTEST_BUILD_HOST_FILES += "configdata.pm"
@@ -170,8 +166,8 @@
cp -r ${S}/external ${B}/test ${S}/test ${B}/fuzz ${S}/util
${B}/util ${D}${PTEST_PATH}
# For test_shlibload
- ln -s ${libdir}/libcrypto.so.1.1 ${D}${PTEST_PATH}/
- ln -s ${libdir}/libssl.so.1.1 ${D}${PTEST_PATH}/
+ ln -s ${libdir}/libcrypto.so.1.0 ${D}${PTEST_PATH}/
+ ln -s ${libdir}/libssl.so.1.0 ${D}${PTEST_PATH}/
install -d ${D}${PTEST_PATH}/apps
ln -s ${bindir}/openssl ${D}${PTEST_PATH}/apps
@@ -192,11 +188,11 @@
FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
FILES_libssl = "${libdir}/libssl${SOLIBS}"
FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf \
- ${libdir}/ssl-1.1/openssl.cnf* \
+ ${libdir}/ssl-1.0/openssl.cnf* \
"
-FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
-FILES_${PN} =+ "${libdir}/ssl-1.1/*"
+FILES_${PN}-engines = "${libdir}/engines-1.0"
+FILES_${PN}-misc = "${libdir}/ssl-1.0/misc"
+FILES_${PN} =+ "${libdir}/ssl-1.0/*"
FILES_${PN}_append_class-nativesdk = "
${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
вот новый получившийся файл:
cat openssl_1.0.2j.bb
SUMMARY = "Secure Socket Layer"
DESCRIPTION = "Secure Socket Layer (SSL) binary and related
cryptographic tools."
HOMEPAGE = "http://www.openssl.org/"
BUGTRACKER = "http://www.openssl.org/news/vulnerabilities.html"
SECTION = "libs/network"
# "openssl" here actually means both OpenSSL and SSLeay licenses apply
# (see meta/files/common-licenses/OpenSSL to which "openssl" is
SPDXLICENSEMAPped)
LICENSE = "openssl"
LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"
DEPENDS = "hostperl-runtime-native"
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
"
SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
SRC_URI[sha256sum] =
"e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
PACKAGECONFIG ?= ""
PACKAGECONFIG_class-native = ""
PACKAGECONFIG_class-nativesdk = ""
PACKAGECONFIG[cryptodev-linux] =
"enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
B = "${WORKDIR}/build"
do_configure[cleandirs] = "${B}"
#| ./libcrypto.so: undefined reference to `getcontext'
#| ./libcrypto.so: undefined reference to `setcontext'
#| ./libcrypto.so: undefined reference to `makecontext'
EXTRA_OECONF_append_libc-musl = " no-async"
EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
# adding devrandom prevents openssl from using getrandom() which is
not available on older glibc versions
# (native versions can be built with newer glibc, but then relocated
onto a system with older glibc)
EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
# Relying on hardcoded built-in paths causes openssl-native to not be
relocateable from sstate.
CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin
-DENGINESDIR=/not/builtin"
CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin
-DENGINESDIR=/not/builtin"
do_configure () {
os=${HOST_OS}
case $os in
linux-gnueabi |\
linux-gnuspe |\
linux-musleabi |\
linux-muslspe |\
linux-musl )
os=linux
;;
*)
;;
esac
target="$os-${HOST_ARCH}"
case $target in
linux-arm*)
target=linux-armv4
;;
linux-aarch64*)
target=linux-aarch64
;;
linux-i?86 | linux-viac3)
target=linux-x86
;;
linux-gnux32-x86_64 | linux-muslx32-x86_64 )
target=linux-x32
;;
linux-gnu64-x86_64)
target=linux-x86_64
;;
linux-mips | linux-mipsel)
# specifying TARGET_CC_ARCH prevents openssl from (incorrectly) adding
target architecture flags
target="linux-mips32 ${TARGET_CC_ARCH}"
;;
linux-gnun32-mips*)
target=linux-mips64
;;
linux-*-mips64 | linux-mips64 | linux-*-mips64el | linux-mips64el)
target=linux64-mips64
;;
linux-microblaze* | linux-nios2* | linux-sh3 | linux-sh4 | linux-arc*)
target=linux-generic32
;;
linux-powerpc)
target=linux-ppc
;;
linux-powerpc64)
target=linux-ppc64
;;
linux-powerpc64le)
target=linux-ppc64le
;;
linux-riscv32)
target=linux-generic32
;;
linux-riscv64)
target=linux-generic64
;;
linux-sparc | linux-supersparc)
target=linux-sparcv9
;;
esac
useprefix=${prefix}
if [ "x$useprefix" = "x" ]; then
useprefix=/
fi
# WARNING: do not set compiler/linker flags (-I/-D etc.) in
EXTRA_OECONF, as they will fully replace the
# environment variables set by bitbake. Adjust the environment
variables instead.
HASHBANGPERL="/usr/bin/env perl" PERL=perl
PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS}
--prefix=$useprefix --openssldir=${libdir}/ssl-1.0 --libdir=${libdir}
$target
perl ${B}/configdata.pm --dump
}
do_install () {
oe_runmake DESTDIR="${D}" MANDIR="${mandir}" MANSUFFIX=ssl install
oe_multilib_header openssl/opensslconf.h
# Create SSL structure for packages such as ca-certificates which
# contain hard-coded paths to /etc/ssl. Debian does the same.
install -d ${D}${sysconfdir}/ssl
mv ${D}${libdir}/ssl-1.0/certs \
${D}${libdir}/ssl-1.0/private \
${D}${libdir}/ssl-1.0/openssl.cnf \
${D}${sysconfdir}/ssl/
# Although absolute symlinks would be OK for the target, they become
# invalid if native or nativesdk are relocated from sstate.
ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.0/certs
ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.0/private
ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.0/openssl.cnf
}
do_install_append_class-native () {
create_wrapper ${D}${bindir}/openssl \
OPENSSL_CONF=${libdir}/ssl-1.0/openssl.cnf \
SSL_CERT_DIR=${libdir}/ssl-1.0/certs \
SSL_CERT_FILE=${libdir}/ssl-1.0/cert.pem \
OPENSSL_ENGINES=${libdir}/engines-1.0
}
do_install_append_class-nativesdk () {
mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
install -m 644 ${WORKDIR}/environment.d-openssl.sh
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
sed 's|/usr/lib/ssl/|/usr/lib/ssl-1.0/|g' -i
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
}
PTEST_BUILD_HOST_FILES += "configdata.pm"
PTEST_BUILD_HOST_PATTERN = "perl_version ="
do_install_ptest () {
# Prune the build tree
rm -f ${B}/fuzz/*.* ${B}/test/*.*
cp ${S}/Configure ${B}/configdata.pm ${D}${PTEST_PATH}
cp -r ${S}/external ${B}/test ${S}/test ${B}/fuzz ${S}/util ${B}/util
${D}${PTEST_PATH}
# For test_shlibload
ln -s ${libdir}/libcrypto.so.1.0 ${D}${PTEST_PATH}/
ln -s ${libdir}/libssl.so.1.0 ${D}${PTEST_PATH}/
install -d ${D}${PTEST_PATH}/apps
ln -s ${bindir}/openssl ${D}${PTEST_PATH}/apps
install -m644 ${S}/apps/*.pem ${S}/apps/*.srl ${S}/apps/openssl.cnf
${D}${PTEST_PATH}/apps
install -m755 ${B}/apps/CA.pl ${D}${PTEST_PATH}/apps
install -d ${D}${PTEST_PATH}/engines
install -m755 ${B}/engines/ossltest.so ${D}${PTEST_PATH}/engines
}
# Add the openssl.cnf file to the openssl-conf package. Make the libcrypto
# package RRECOMMENDS on this package. This will enable the configuration
# file to be installed for both the openssl-bin package and the libcrypto
# package since the openssl-bin package depends on the libcrypto package.
PACKAGES =+ "libcrypto libssl openssl-conf ${PN}-engines ${PN}-misc"
FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
FILES_libssl = "${libdir}/libssl${SOLIBS}"
FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf \
${libdir}/ssl-1.0/openssl.cnf* \
"
FILES_${PN}-engines = "${libdir}/engines-1.0"
FILES_${PN}-misc = "${libdir}/ssl-1.0/misc"
FILES_${PN} =+ "${libdir}/ssl-1.0/*"
FILES_${PN}_append_class-nativesdk = "
${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
RRECOMMENDS_libcrypto += "openssl-conf"
RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"
RDEPENDS_${PN}-bin += "openssl-conf"
BBCLASSEXTEND = "native nativesdk"
CVE_PRODUCT = "openssl:openssl"
# Only affects OpenSSL >= 1.1.1 in combination with Apache < 2.4.37
# Apache in meta-webserver is already recent enough
CVE_CHECK_WHITELIST += "CVE-2019-0190"
I understand that I need to figure out the configs yourself, but I get
this error when executing the
bitbake openssl-native
ERROR: Execution of
'/home/ivr/work/yocto_orig/build/tmp/work/x86_64-linux/openssl-native/1.0.2j-r0/temp/run.do_configure.1071458'
failed with exit code 2:
| unable to read opensslv.h:No such file or directory
| Configuring for linux-x86_64
| no-devcryptoeng [option] OPENSSL_NO_DEVCRYPTOENG (skip dir)
| no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
(skip dir)
| no-gmp [default] OPENSSL_NO_GMP (skip dir)
| no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
| no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
| no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
| no-md2 [default] OPENSSL_NO_MD2 (skip dir)
| no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
| no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
| no-sctp [default] OPENSSL_NO_SCTP (skip dir)
| no-shared [default]
| no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
| no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir)
| no-store [experimental] OPENSSL_NO_STORE (skip dir)
| no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
| no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
| no-zlib [default]
| no-zlib-dynamic [default]
| IsMK1MF=0
| WARNING: exit code 2 from a shell command.
|
As far as I can understand, the opensslv.h file is generated just at
the configuration stage, why does the configuration stage give an
error of the absence of this file?


Re: editing Makefile after configure stage to disable -Werror

Ivan Riabtsov <ivriabtsov@...>
 

i cleaned out -Werror wherever possible with command:

sed -i 's/-Werror//g' $(find . -type f -exec egrep -l _no_Werror {} \;)

and elfutils is builded

вт, 31 авг. 2021 г. в 09:41, Ivan Riabtsov via lists.yoctoproject.org
<ivriabtsov=gmail.com@...>:


Hello, I have the following error:

../../elfutils-0.166/libelf/libelfP.h:53:30: error: ‘__elf64_msize’
specifies less restrictive attribute than its target ‘elf64_fsize’:
‘const’ [-Werror=missing-attributes]

i try to solve this by patch:

diff -Naur elfutils-0.166_orig/libelf/libelfP.h elfutils-0.166/libelf/libelfP.h
--- elfutils-0.166_orig/libelf/libelfP.h 2016-01-12 15:49:19.000000000 +0300
+++ elfutils-0.166/libelf/libelfP.h 2021-08-30 19:38:44.866175082 +0300
@@ -48,6 +48,8 @@


/* Helper Macros to write 32 bit and 64 bit functions. */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmissing-attributes"
#define __elfw2_(Bits, Name) __elf##Bits##_##Name
#define elfw2_(Bits, Name) elf##Bits##_##Name
#define ElfW2_(Bits, Name) Elf##Bits##_##Name
@@ -632,4 +634,5 @@
#define INVALID_NDX(ndx, type, data) \
unlikely ((data)->d_size / sizeof (type) <= (unsigned int) (ndx))

+#pragma GCC diagnostic pop
#endif /* libelfP.h */


But the patch does not work, error appears again.


i try to add --disable-werror to configure flags, but i have follows warning:

configure: WARNING: unrecognized options: --disable-werror.


The only solution to the problem I could think of is editing the
Makefile after configuration, please tell me how this can be done?



Re: extrausers-bbclass: plaintext password (since shadow update to 4.9)

Peter Bergin
 

Hi Matthias,

On 2021-08-31 09:03, Matthias Klein wrote:
But I have not found a way to set the password with EXTRA_USERS_PARAMS.
Do you know a working variant?
Is it a requirement that you need to regenerate the hash on every build? If not one solution can be:

    inherit extrausers

    #
    # HASH generated with this command:
    # python3 -c "import crypt; print(crypt.crypt('toor', crypt.METHOD_SHA512))"
    #
    HASH = "\\\$6\\\$8Z5vMcqCIB19PgY8\\\$Sv4kAfsH1k.SANHL5JVb6hdqmQWHOeH0Rjrjyii7fGAK20Gclj/.qiBvUPnAfh.WSsr1.XV0pUNom2L9oYYDV/"

    EXTRA_USERS_PARAMS = " \
       usermod -p ${HASH} root; \
    "

Best regards,
/Peter


Re: extrausers-bbclass: plaintext password (since shadow update to 4.9)

Matthias Klein
 

Hello Peter,

I have already tried many things to pass the hash escaped to the extrausers-bbclass.

But I have not found a way to set the password with EXTRA_USERS_PARAMS.
Do you know a working variant?

Many greetings,
Matthias

-----Ursprüngliche Nachricht-----
Von: Peter Bergin <peter@...>
Gesendet: Montag, 30. August 2021 22:52
An: Matthias Klein <matthias.klein@...>; yocto@...
Betreff: Re: [yocto] extrausers-bbclass: plaintext password (since shadow update to 4.9)

On 2021-08-30 14:54, Matthias Klein wrote:

Hello,

I am trying to find a working alternative for the old -P option.

Previous:
EXTRA_USERS_PARAMS = "usermod -P toor root;"

The suggestions from this thread don't seem to work:
https://lists.openembedded.org/g/openembedded-core/topic/84548199

Current:
hash="$(python3 -c "import crypt; print(crypt.crypt('toor', crypt.METHOD_SHA512))")"
EXTRA_USERS_PARAMS = "usermod -p ${hash} root;"

The hashed password does not seem to be escaped properly in the extrausers-bbclass. The password in the shadow file is missing $ characters.

Is there a way (with the current master branch) to define a password?

You have to escape the password string in the recipe. Use '\\\$' to escape the '$' token. There are some levels of evaluation of the expression and that's the reason for multiple '\'. Just iterate until you have the correct string in the shadow file, also check the log.do_rootfs where you can see the parameters to usermod.

/Peter


Re: extrausers-bbclass: plaintext password (since shadow update to 4.9)

Matthias Klein
 

Hello Markus,

thanks for the workaround!
Works great.

Many greetings,
Matthias


Von: Markus Volk <f_l_k@...>
Gesendet: Montag, 30. August 2021 20:46
An: Matthias Klein <matthias.klein@...>
Cc: yocto@...
Betreff: Re: [yocto] extrausers-bbclass: plaintext password (since shadow update to 4.9)

I also have problems with setting passwords in current master branch. I only can provide a hacky workaround. I added the following lines to my image recipe to inject the passwords manually after rootfs creation:

RETRO_USER_PASSWORD ?= "retro"
ROOT_USER_PASSWORD ?= "root"
ROOTFS_POSTPROCESS_COMMAND += "set_root_passwd;"
ROOTFS_POSTPROCESS_COMMAND += "set_retro_passwd;"

set_root_passwd() {
   ROOTPW_ENCRYPTED="$(openssl passwd -6 -salt xyz ${ROOT_USER_PASSWORD})"
   sed -i "s%^root:[^:]*:%root:${ROOTPW_ENCRYPTED}:%" ${IMAGE_ROOTFS}/etc/shadow
}

set_retro_passwd() {
   RETROPW_ENCRYPTED="$(openssl passwd -6 -salt xyz ${RETRO_USER_PASSWORD})"
   sed -i "s%^retro:[^:]*:%retro:${RETROPW_ENCRYPTED}:%" ${IMAGE_ROOTFS}/etc/shadow
}

Am 30.08.21 um 14:54 schrieb Matthias Klein:
Hello,

I am trying to find a working alternative for the old -P option.

Previous:
EXTRA_USERS_PARAMS = "usermod -P toor root;"

The suggestions from this thread don't seem to work: https://lists.openembedded.org/g/openembedded-core/topic/84548199

Current:
hash="$(python3 -c "import crypt; print(crypt.crypt('toor', crypt.METHOD_SHA512))")"
EXTRA_USERS_PARAMS = "usermod -p ${hash} root;"

The hashed password does not seem to be escaped properly in the extrausers-bbclass. The password in the shadow file is missing $ characters.

Is there a way (with the current master branch) to define a password?

Many greetings,
Matthias


editing Makefile after configure stage to disable -Werror

Ivan Riabtsov <ivriabtsov@...>
 

Hello, I have the following error:

../../elfutils-0.166/libelf/libelfP.h:53:30: error: ‘__elf64_msize’
specifies less restrictive attribute than its target ‘elf64_fsize’:
‘const’ [-Werror=missing-attributes]

i try to solve this by patch:

diff -Naur elfutils-0.166_orig/libelf/libelfP.h elfutils-0.166/libelf/libelfP.h
--- elfutils-0.166_orig/libelf/libelfP.h 2016-01-12 15:49:19.000000000 +0300
+++ elfutils-0.166/libelf/libelfP.h 2021-08-30 19:38:44.866175082 +0300
@@ -48,6 +48,8 @@


/* Helper Macros to write 32 bit and 64 bit functions. */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmissing-attributes"
#define __elfw2_(Bits, Name) __elf##Bits##_##Name
#define elfw2_(Bits, Name) elf##Bits##_##Name
#define ElfW2_(Bits, Name) Elf##Bits##_##Name
@@ -632,4 +634,5 @@
#define INVALID_NDX(ndx, type, data) \
unlikely ((data)->d_size / sizeof (type) <= (unsigned int) (ndx))

+#pragma GCC diagnostic pop
#endif /* libelfP.h */


But the patch does not work, error appears again.


i try to add --disable-werror to configure flags, but i have follows warning:

configure: WARNING: unrecognized options: --disable-werror.


The only solution to the problem I could think of is editing the
Makefile after configuration, please tell me how this can be done?


Re: [oe][meta-security][PATCH] meta: Fix typos

Armin Kuster
 

On 8/29/21 1:04 AM, Martin Jansa wrote:
Please merge this one.
you are right. Some how dropped that one. Its merged not.

thanks for the reminder.

-armin

On Wed, Aug 4, 2021 at 1:20 PM Martin Jansa via lists.yoctoproject.org
<http://lists.yoctoproject.org>
<Martin.Jansa=gmail.com@...
<mailto:gmail.com@...>> wrote:

Acked-by: Martin Jansa <Martin.Jansa@...
<mailto:Martin.Jansa@...>>

On Mon, Aug 2, 2021 at 11:02 AM George Liu <liuxiwei1013@...
<mailto:liuxiwei1013@...>> wrote:

Fix the variable spelling errors
s/SKIP_META_SECUIRTY_SANITY_CHECK/SKIP_META_SECURITY_SANITY_CHECK

Signed-off-by: George Liu <liuxiwei@...
<mailto:liuxiwei@...>>
---
 classes/sanity-meta-security.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/sanity-meta-security.bbclass
b/classes/sanity-meta-security.bbclass
index b6c6b9c..f9e2698 100644
--- a/classes/sanity-meta-security.bbclass
+++ b/classes/sanity-meta-security.bbclass
@@ -1,7 +1,7 @@
 addhandler security_bbappend_distrocheck
 security_bbappend_distrocheck[eventmask] = "bb.event.SanityCheck"
 python security_bbappend_distrocheck() {
-    skip_check =
e.data.getVar('SKIP_META_SECUIRTY_SANITY_CHECK') == "1"
+    skip_check =
e.data.getVar('SKIP_META_SECURITY_SANITY_CHECK') == "1"
     if 'security' not in
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:
         bb.warn("You have included the meta-security layer, but \
 'security' has not been enabled in your DISTRO_FEATURES. Some
bbappend files \
--
2.30.2







M+ & H bugs with Milestone Movements WW35

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW35 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13025

WIC image install support

kexin.hao@...

kexin.hao@...

3.5

3.5 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW35!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

1

randy.macleod@...

1

Grand Total

2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW35 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 42 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

michael.opdenacker@...

32

ross@...

31

david.reyna@...

22

richard.purdie@...

22

bruce.ashfield@...

16

randy.macleod@...

15

trevor.gamblin@...

13

timothy.t.orling@...

12

JPEWhacker@...

10

sakib.sajal@...

10

bluelightning@...

7

kai.kang@...

7

mhalstead@...

6

tony.tascioglu@...

5

Qi.Chen@...

4

hongxu.jia@...

4

chee.yang.lee@...

3

mingli.yu@...

3

alexandre.belloni@...

2

jaewon@...

2

yi.zhao@...

2

yf3yu@...

2

mshah@...

2

akuster808@...

2

alejandro@...

2

jay.shen.teoh@...

1

diego.sueiro@...

1

john.kaldas.enpj@...

1

sangeeta.jain@...

1

douglas.royds@...

1

mostthingsweb@...

1

mister_rs@...

1

raj.khem@...

1

devendra.tewari@...

1

kergoth@...

1

thomas.perrot@...

1

dl9pf@...

1

tonyb@...

1

open.source@...

1

fransmeulenbroeks@...

1

Martin.Jansa@...

1

yoctoproject@...

1

nicolas.dechesne@...

1

naveen.kumar.saini@...

1

jon.mason@...

1

jason.wessel@...

1

jeanmarie.lemetayer@...

1

ydirson@...

1

aehs29@...

1

pokylinux@...

1

matthewzmd@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 382 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: extrausers-bbclass: plaintext password (since shadow update to 4.9)

Peter Bergin
 

On 2021-08-30 14:54, Matthias Klein wrote:

Hello,

I am trying to find a working alternative for the old -P option.

Previous:
EXTRA_USERS_PARAMS = "usermod -P toor root;"

The suggestions from this thread don't seem to work: https://lists.openembedded.org/g/openembedded-core/topic/84548199

Current:
hash="$(python3 -c "import crypt; print(crypt.crypt('toor', crypt.METHOD_SHA512))")"
EXTRA_USERS_PARAMS = "usermod -p ${hash} root;"

The hashed password does not seem to be escaped properly in the extrausers-bbclass. The password in the shadow file is missing $ characters.

Is there a way (with the current master branch) to define a password?

You have to escape the password string in the recipe. Use '\\\$' to escape the '$' token. There are some levels of evaluation of the expression and that's the reason for multiple '\'. Just iterate until you have the correct string in the shadow file, also check the log.do_rootfs where you can see the parameters to usermod.

/Peter

3201 - 3220 of 57789