We don't need the legacy provider, so don't load it. This avoids
problems in a no-legacy build
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
If the legacy provider isn't available then we shouldn't attempt to
load or use it.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
test_enc should not test ciphers that are not available due to a lack
of the legacy provider
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
In spite of the name the endecoder_legacy_test does not need the
legacy provider. Therefore we avoid loading it so that no-legacy
builds still run the test successfully.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
If we've been configured with no-legacy then we should not attempt to
load the legacy provider.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
We skip a test that uses the no-legacy option. Unfortuantely there is
no OPENSSL_NO_LEGACY to test, so we just check whether we were successful
in loading the legacy provider - and if not we skip the test.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13595)
no-asm has proven to be too slow, therefore we don't use it in the Github
CI builds and instead rely on it being covered by run-checker.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/13607)
This includes a general correction in the code (now using the X509V3_CTX_REPLACE flag)
and adding a prominent clarification in the documentation:
If multiple entries are processed for the same extension name,
later entries override earlier ones with the same name.
This is due to an RFC 5280 requirement - the intro of its section 4.2 says:
A certificate MUST NOT include more than one instance of a particular extension.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13614)
MIDR_EL1 system register exposes microarchitecture information so that
people can make micro-arch related optimization such as exposing as
much instruction level parallelism as possible.
MIDR_EL1 register can be read only if HWCAP_CPUID feature is supported.
Change-Id: Iabb8a36c5d31b184dba6399f378598058d394d4e
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11744)
If an SNI callback has been set then we may have no certificuates suitable
for TLSv1.3 use configured for the current SSL_CTX. This should not prevent
us from negotiating TLSv1.3, since we may change the SSL_CTX by the time we
need a suitable certificate.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13304)
A servername cb may change the available certificates, so if we have one
set then we cannot rely on the configured certificates to determine if we
are capable of negotiating TLSv1.3 or not.
Fixes#13291
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13304)
This satisfies EVP's RAND layer.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13640)
This allows the operating system sources that OpenSSL supports to be
used directly as RNGs. It also allows DRBG seeding to be explicitly
specified rather than being left to a fall back case.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13455)
For the moment, we translate the result to a NID, because that's still
used in several locations in libssl. Future development should change
all the internals to be name based instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13436)
This replaces the internal evp_pkey_get_EC_KEY_curve_nid()
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13436)
call level.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)
This commit clears the error that might have been set when
ossl_store_get0_loader_int has been called as it will try to retrieve
a loader for the scheme on an empty store, which will cause the error
OSSL_STORE_R_UNREGISTERED_SCHEME to be set.
The motivation for this after returning from
ossl_store_get0_loader_int, OSSL_STORE_attach will continue and try to
fetch a OSSL_STORE_LOADER from the provider.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12901)
The ERR_load_*_strings() functions were not being defined in a no-err
build. This is an API break since in 1.1.1 they were still present in a
no-err build, but were no-ops. This was also causing a failure in
test_symbol_presence. We revert to the way things were done in 1.1.1,
i.e. in a no-err build the functions are still present but are no-ops.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13598)
If we're using TLSv1.2 then the test_sigalgs_available test needs to be
careful which ciphersuite is selected in order for the test to behave
correctly.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13596)
This protects us from unwanted GENERATE statements in particular.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/13626)
If you have a CHOICE type that it must use explicit tagging - otherwise
the template is invalid. We add tests for this.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
It never makes sense for multi-string or CHOICE types to have implicit
tagging. If we have a template that uses the in this way then we
should immediately fail.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
It never makes sense for multi-string or CHOICE types to use implicit
tagging since the content would be ambiguous. It is an error in the
template if this ever happens. If we detect it we should stop parsing.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
If a GENERAL_NAME field contained EdiPartyName data then it was
incorrectly being handled as type "other". This could lead to a
segmentation fault.
Many thanks to David Benjamin from Google for reporting this issue.
CVE-2020-1971
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
