Drop redundant setting of S to its default value and re-order
variables to align more closely to the OE style-guide.
(From OE-Core rev: 4871481e66449dd2b054119b37d0baedb166b72c)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using += with an over-ride can be a source of confusion so try to
avoid the construct in core recipes.
The current usage is incorrect and prevents the aarch64 and musl
specific config options from being active together.
(From OE-Core rev: 2a30a9ecab6465892698f7fc9d14a430d8a26f0c)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When SDK is not installed in the default location, openssl will not be
able to find the the openssl.cnf config file:
"WARNING: can't open config file: XXXX/usr/lib/ssl/openssl.cnf"
To fix this, we need to provide the environment variable $OPENSSL_CONF
pointing to the correct config file location.
(From OE-Core rev: b3f148333515efdb746b78c57d62cfbf3321b21e)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ccache and openssl don't get on:
| make[1]: Entering directory '/home/prj/yocto/build/tmp/work/core2-64-poky-linux/openssl/1.0.2o-r0/openssl-1.0.2o/crypto'
| ccache: invalid option -- 'D'
Disable the use of ccache in the openssl recipe until someone root-causes this.
[ YOCTO #12810 ]
(From OE-Core rev: 8f9ceebb197dba10f2d08449de2dd64584de06bb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Please see this security advisory:
https://www.openssl.org/news/secadv/20180327.txt
License-Update: copyright years
(From OE-Core rev: 13542282e34c078296c46a98721b31ed9a69a980)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks when libdir is '/usr/lib/tuple', leading to libraries ending up in '/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the prefix instead.
(From OE-Core rev: e58d5521c7bae8daafdac85754545be176550a02)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve reproducible build of:
openssl-staticdev
openssl-dbg
libcrypto
There are two main causes that prevent reproducible build, both related to
the generated file "buildinf.h":
1. "buildinf.h" contains build host CFLAGS, containing various build
host references. We need to pass sanitized CFLAGS to the script
generating this file ("mkbuildinf.pl". )
2. We also need to modify the script "mkbuildinf.pl" itsel in order to
generate a build timestamp based on SOURCE_DATE_EPOCH, if present in
the environment.
(From OE-Core rev: 6c556ed3553d8f5e75d65cd7db92b26df43846b7)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch was applied in a completely incorrect spot (due to fuzz),
no one noticed or complained. Meanwhile upstream says the issue
has been resolved differently:
https://rt.openssl.org/Ticket/Display.html?id=3759&user=guest&pass=guest
(From OE-Core rev: 325e516b59e677dc8e2c5756589fa8037b3e9392)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 7baba7a19c5610a63ccbfd6a2238667772b32118)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop upstreamed 0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
Rebase a couple more patches (via devtool upgrade).
(From OE-Core rev: 8a79b8619ce797d5395989e7bb804bc2accfbb14)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
(From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
(From OE-Core rev: e76dcfbd6e1ad6fc147a0607dcdaf8e7ea98b610)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
(From OE-Core rev: edf9686be28fc321886d48043bcb4ef5b2c00c1d)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
(From OE-Core rev: 977db3843b629112539d3eb766c845127c0de497)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
(From OE-Core rev: a200115c769eff4b9b0241d54ed5ad86da08fdbc)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch works around a rare parallel build race condition using
the force option when soft linking.
The error seen is:
ln: failed to create symbolic link 'libssl.so': File exists
make[4]: *** [Makefile.shared:171: link_a.gnu] Error 1
make[4]: Leaving directory
'/.../build/tmp-glibc/work/x86_64-linux/openssl-native/1.0.2k-r0/openssl-1.0.2k'
Just add the -f flag to the platform independent soft link code to
avoid the collision. This is reasonable since this Makefile removes
the link target before creating a new soft link. The Makefile was
written this way to support platforms that don't allow forcing a
softlink to overwrite an existing link. Only builds on Linux are
supported so that's not a requirement for oe-core recipes.
The openssl team is rewriting their build files so it's not appropriate
for openssl upstream and fixing the root cause of the race condition
was also not pursued.
(From OE-Core rev: c60288aba70635238094c6b813228b31e0715db9)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
openssl 1.1 broke 3rd party layers a lot more than was expected; let's flip
the switch at the start of next development cycle.
Add a PROVIDES = "openssl10" to openssl 1.0 recipe; any dependency that is
not compatible with 1.1 should use that in its DEPENDS, as the 1.0
recipe will later be renamed back to openssl10. This does not always work:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140957.html
but for many recipes it does.
(From OE-Core rev: 5585103c195104e85ed7ac1455bef91b2e88a04d)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: openssl-1.1.0f-r0 do_package_qa: QA Issue: /usr/lib/openssl/ptest/fuzz/helper.py contained in package openssl-ptest requires /usr/bin/python, but no providers found in RDEPENDS_openssl-ptest? [file-rdeps]
ERROR: openssl-1.1.0f-r0 do_package_qa: QA Issue: /usr/lib/openssl/ptest/test/certs/mkcert.sh contained in package openssl-ptest requires /bin/bash, but no providers found in RDEPENDS_openssl-ptest? [file-rdeps]
(From OE-Core rev: 7e70d0673df20669edd18b79ae065d8c2f655b8a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The package resolver failes to assemble images because some of the man
pages in openssl10 conflict with the openssl package. In the case
where you want openssl, openssh and the documentation installed in the
same system you will see the failure.
The work around is to rename all the openssl10 man pages and symlinks
to have a prefix of openssl10-.
(From OE-Core rev: bb837cae92472b294ac886b121b2249e4314439f)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing openssl 1.0 recipe is renamed to openssl10; it will
continue to be provided for as long as upstream supports it
(and there are still several recipes which do not work with openssl
1.1 due to API differences).
A few files (such as openssl binary) are no longer installed by openssl 1.0,
because they clash with openssl 1.1.
(From OE-Core rev: da1183f9fa5e06fbe66b5b31eb3313d5d35d11e3)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support musl-x32 build which to build openssl with 32 bits.
(From OE-Core rev: a072d4620db462c5d3459441d5684cfd99938400)
Signed-off-by: sweeaun <swee.aun.khor@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Dropped obsolete patches, because the new version contains them:
- fix-cipher-des-ede3-cfb1.patch
- openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
2. LICENSE checksum change due to copyright years and wording tweak.
3. Test binaries (x86-64) are included in source code. So remove those
only for ptest.
(From OE-Core rev: 64ec18d7e13d310e5e44080a04b3f2181ea96ae3)
Signed-off-by: Changhyeok Bae <changhyeok.bae@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds or fixes the Upstream-Status for all remaining patches missing it
in OE-Core.
(From OE-Core rev: 563cab8e823c3fde8ae4785ceaf4d68a5d3e25df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of these are clearly dead, e.g. one binutils patch reverts the effects
of the earlier one.
This also removes the uclibc site files. We now have mechanisms to allow these
to be extended from another layer should someone ever wish to do that.
(From OE-Core rev: e01e7c543a559c8926d72159b5cd55db0c661434)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 7933fbbc637 "Security fix Drown via 1.0.2g update" included
a version-script change from Debian that was an ABI change. It did
not include the soname change that Debian did so we have been calling
our ABI 1.0.0 but it really matches what others call 1.0.2.
Bump SONAME to match the ABI. In practice this changes both libcrypto
and libssl sonames from 1.0.0 to 1.0.2.
For background: Upstream does not do sonames so these are set by
distros. In this case the ABI changes based on a build time
configuration! Debian took the ABI changing configuration and bumped
soname but e.g. Ubuntu kept the deprecated API and just made it not
work, keeping soname. So both have same version of openssl but support
different ABI (and expose different SONAME).
Fixes [YOCTO #11396].
Thanks to Alexander Larsson et al for detective work.
(From OE-Core rev: 1b430eef7131876bc735c22d66358379b0516821)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 991620f3962a9917fa99abb5582f4b72ebd42a3d.
The commit breaks openssl-native (you can no longer generate keys
because it can't find the configuration file). Also the idea that we
would install configuration files normally but then add the symlinks
pointing to them in a postinstall feels wrong.
Fixes [YOCTO #11296]. The bug contains an alternative fix but I'm
sending a revert as I cannot fully understand the motive of the
original patch. See also discussion in
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135176.html
(From OE-Core rev: b192daef5d1e7f3501c533b92dc75e2d996afc13)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was causing a couple of ptest failures.
[YOCTO #10840]
(From OE-Core rev: 2e8e72790d3cc3236b6a785f3e04702e71e1ac3f)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the
default openssl version. Openssl 1.0 will stay but will be renamed
to openssl10, and eventually it will be removed (hopefully much
sooner than the official end of support date of Dec 2019, as we do not
want an unsupported openssl version in supported Yocto releases).
There are several recipes that are not API compatible with 1.1; some
of them will eventually be fixed, but others will never be (such as Qt4).
To avoid breaking such recipes when openssl 1.1 is added to oe-core,
let's provide "openssl10" already now and change the recipes to depend
on that where necessary; Qt4 is a particularly pressing issue as it is
causing failures on the autobuilder with my work in progress
openssl 1.1 branch, and so I'm not able to see what else would fail
later in the build process.
(From OE-Core rev: cffc3a88608bd295eb1220fadae56eb4676414df)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 'c8da8ce openssl: Fix build with clang' introduced a regression.
do_compile fails when building with gcc/thumb2.
Note that I did not test if it still builds with clang.
Prevents the following when building with thumb2:
| ghash-armv4.S: Assembler messages:
| ghash-armv4.S:88: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r2,r3]'
| ghash-armv4.S:98: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:98: Error: thumb conditional instruction should be in IT block -- `ldrplb r8,[r0,r3]'
| ghash-armv4.S:105: Error: thumb conditional instruction should be in IT block -- `eorpl r12,r12,r8'
| ghash-armv4.S:107: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:108: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'
| ghash-armv4.S:144: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:144: Error: thumb conditional instruction should be in IT block -- `ldrneb r12,[r2,#15]'
| ghash-armv4.S:231: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:231: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r0,r3]'
| ghash-armv4.S:248: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:249: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'
(From OE-Core rev: 65cfb24033278fd4fb27013d3272394197649ca2)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The OpenSSL recipe tried to workaround the -e make flag (overriding
variables from the environment). And when the -e flag was dropped as
the global default, it was specifically added for OpenSSL. This is
unnecessary, as only the value of ${AR} seems to be affected, and that
can be handled correctly by OpenSSL's build system if we just let it.
(From OE-Core rev: 537a404cfbb811fcb526cdb5f2e059257de6ef13)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch was added to fix a CVE, but wasn't actually added to SRC_URI:
CVE: CVE-2004-2761
The MD5 Message-Digest Algorithm is not collision resistant,
which makes it easier for context-dependent attackers to
conduct spoofing attacks, as demonstrated by attacks on the
use of MD5 in the signature algorithm of an X.509 certificate.
(From OE-Core rev: 8791800f84321b3f46772bc2d9e4f754e6213946)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Symlinking the openssl configuration file at install time results in
errors when overriding it using an external package which also provides
openssl-conf. This should be done as a postinstall task for such
packages.
(From OE-Core rev: 991620f3962a9917fa99abb5582f4b72ebd42a3d)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Absolute path symlinks are a bit of a pain for sstate and the native versions
of these recipes currently contain broken symlinks as a result. There are
only a small number of problematic recipes, at least in OE-Core, namely the
three here.
Rather than trying to make sstate handle this magically, which turns out to
be a harder problem than you'd first realise, simply make the symlinks relative
early in the process and avoid all the problems.
The alternative is adding new complexity to sstate which we could really
do without as without the complexity, you can't always tell where the
absolute symlink is relative to (due to prefixes used for native sstate).
(From OE-Core rev: e478550c8cd889f12e336e268e9e3b30827bf840)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 target was being configured for linux-generic64 but openssl has
linux-aarch64 target. Change to use linux-aarch64 as default.
(From OE-Core rev: 13e9a692510151383bc3243c3917154896b0e049)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes
| /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32 against undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value
(From OE-Core rev: 0a19e72081771fca8ed94fb2a2a8996fd3dce00c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits.
External References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7055https://www.openssl.org/news/secadv/20161110.txt
Patch from:
57c4b9f6a2
(From OE-Core rev: 07cfa9e2bceb07f3baf40681f8c57f4d3da0aee5)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use SHA256 as default digest for OpenSSL instead of MD5.
CVE: CVE-2004-2761
The MD5 Message-Digest Algorithm is not collision resistant,
which makes it easier for context-dependent attackers to
conduct spoofing attacks, as demonstrated by attacks on the
use of MD5 in the signature algorithm of an X.509 certificate.
Upstream-Status: Backport
Backport from OpenSSL 2.0 to OpenSSL 1.0.2
Commit f8547f62c212837dbf44fb7e2755e5774a59a57b
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(From OE-Core rev: f924428cf0c22a0b62769f8f31f11f173f25014f)
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: T.O. Radzy Radzykewycz <radzy@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script claims to be a /bin/sh script, but it uses
a bashism:
from checkbashisms:
possible bashism in meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh line 151 (should be 'b = a'):
if [ "x/" == "x$( echo ${FILE} | cut -c1 -)" ]
This causes build issues on systems that don't have
/bin/sh symlinked to bash:
Updating certificates in ${WORKDIR}/rootfs/etc/ssl/certs...
<builddir>/tmp/sysroots/x86_64-linux/usr/bin/c_rehash: 151: [: x/: unexpected operator
...
Fix this by using POSIX shell syntax for the comparison.
(From OE-Core rev: 0526524c74d4c9019fb014a2984119987f6ce9d3)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Reviewed-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The c_rehash utility is supposed to be run in the folder /etc/ssl/certs
of a rootfs where the package ca-certificates puts symlinks to
various CA certificates stored in /usr/share/ca-certificates/mozilla/.
These symlinks are absolute. This means that when c_rehash is run
at rootfs creation time it can't hash the actual files since they
actually reside in the build host's directory
$SYSROOT/usr/share/ca-certificates/mozilla/.
This problem doesn't reproduce when building on Debian or Ubuntu
hosts though, because these OSs have the certificates installed
in the same /usr/share/ca-certificates/mozilla/ folder.
Images built in other distros, e.g. Fedora, have problems with
connecting to https servers when using e.g. python's http lib.
The patch fixes c_rehash to check if it runs on a build host
by testing $SYSROOT and to translate the paths to certificates
accordingly.
(From OE-Core rev: 5199b990edf4d9784c19137d0ce9ef141cd85e46)
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
