Openssl 3.2 has reached EOL.
Some projects would like to use LTS version due to criticality and
exposure of this component, so upgrade to 3.5 branch.
Copy recipe from oe-core master fd3b1efb6f7ffb5505ff7eb95cae222e1db9f776
which is the last revision before disabling TLS 1/1.1 by default.
Single change is replacing UNPACKDIR by WORKIDR (one occurence).
(From OE-Core rev: c4fc6ee6986fbd05d72bf1e6bb1d2c4eee84e5db)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When Bash runs with 'set -u' (nounset), accessing an unset variable
directly (e.g. [ -z "$SSL_CERT_FILE" ]) causes a fatal "unbound variable"
error. As a result, the fallback logic to set SSL_CERT_FILE/SSL_CERT_DIR
is never triggered and the script aborts.
The current code assumes these variables may be unset or empty, but does
not guard against 'set -u'. This breaks builds in stricter shell
environments or when users explicitly enable 'set -u'.
Fix this by using parameter expansion with a default value, e.g.
"${SSL_CERT_FILE:-}", so that unset variables are treated as empty
strings. This preserves the intended logic (respect host env first, then
CAFILE/CAPATH, then buildtools defaults) and makes the script robust
under 'set -u'.
(From OE-Core rev: 4cf131ebd157b79226533b5a5074691dd0e1a4ab)
Signed-off-by: Haixiao Yan <haixiao.yan.cn@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4d880c2eccd534133a2a4e6579d955605c0956ec)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: 0653b96bac6d0800dc5154557706a323418808be)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* 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: 5f4fd544d3df7365224599c9efdce4e545f51d5e)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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>
