To adapt user network enviroment, buildtools should first try to use
the user configured envs like SSL_CERT_FILE/CURL_CA_BUNDLE/..., if these
envs is not set, then use the auto-detected ca file and ca path, and
finally use the CA certificates in buildtools.
nativesdk-openssl set OPENSSLDIR as "/not/builtin", need set SSL_CERT_FILE/SSL_CERT_DIR to work
nativesdk-curl don't set default ca file, need
SSL_CERT_FILE/SSL_CERT_DIR or CURL_CA_BUNDLE/CURL_CA_PATH to work
nativesdk-git actually use libcurl, and GIT_SSL_CAPATH/GIT_SSL_CAINFO
also works
nativesdk-python3-requests will use cacert.pem under python module certifi by
default, need to set REQUESTS_CA_BUNDLE
(From OE-Core rev: 8a7ec52e9b35654bee48cd948c6c34c63db3e265)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* make git,curl,python3-requests align with openssl, move the setting of
envvars into respective envfile
* for environment.d-openssl.sh, also check if ca-certificates.crt exist
before export envvars
(From OE-Core rev: 9d8ebfcd55ad274e79cb81f162397c8f39f4287b)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A long time ago, the environment.d-openssl.sh file was shared between
openssl 1.0 and openssl 1.1 recipes, and sed was used to make the path
right for the 1.1 version. Nowadays, with only a single recipe, this
is a bit roundabout, so just use the proper path in the file directly.
(From OE-Core rev: 291fe7db623b0974e7831e908e91b1f1259e0506)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that bitbake uses websockets over SSL as hashserv and is correctly
limiting hash equivalence only to things in the orginal SDK, bitbake builds
from buildtools can fail due to broken SSL from buildtools.
The issue is that the relocation variables are being removed from the
environment. This could be fixed within bitbake or it could be fixed
within the SDK environment. This patch does the latter for now. We
really need to improve openssl relocation within the SDK in general.
Fixing this has become more urgent to fix failing builds in automated
testing.
(From OE-Core rev: 6a20667c166fa3d7e2b6e8e8b442dec0fc75f349)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE-Core d6b15d1e70b99185cf245d829ada5b6fb99ec1af,
"openssl: export necessary env vars in SDK", the value added for
SSL_CERT_FILE was in conflict with the value used elsewhere, such as
in buildtools. This makes them match and fixes buildtools testsdk
failures.
(From OE-Core rev: 7d383a7fc6da666c80f2fc037af5f49a3388eb2b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In current SDK, when running the following command in python
shell, we get an error.
$ python3
>>> from cryptography.hazmat.backends import openssl
The error message is as below:
cryptography.exceptions.InternalError: Unknown OpenSSL error.
We could set OPENSSL_MODULES explicitly in nativesdk-openssl package
so that when SDK is set up, it's in environment and we can
get rid of the above error.
Also, there are other env vars that need to be exported. And we export
all of them to keep sync with openssl-native.bbclass.
(From OE-Core rev: d6b15d1e70b99185cf245d829ada5b6fb99ec1af)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I believe the time has come to do this: openssl 1.0 upstream support stops at the end
of 2019, and we do not want a situation where a supported YP release contains an
unsupported version of a critical security component.
Openssl 1.0 can still be utilized by depending on 'openssl10' recipe.
(From OE-Core rev: 876466145f2da93757ba3f92177d0f959f5fe975)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
