The functions that check for the provider being runnable are: new, init, final
and dupctx.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
The functions that check for the provider being runnable are: new, gen_init,
gen, gen_set_template, load, has, match, validate, import and export.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
The functions that check for the provider being runnable are: newctx, dupctx,
init, derive and set peer.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
Check for provider being runnable in instantiate, reseed, generate and new calls.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
Note that although this is a false positive currently, it could become possible if any of the methods called
change behaviour - so it is safer to add the fix than to ignore it. Added a simple test so that I could prove this was the case.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12847)
The conditions for a valid implementation allowed the 'decode'
function to be NULL or the 'export_object' was NULL. That condition
is changed so that 'decode' is checked to be non-NULL by itself.
Fixes#12819
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12849)
On most systems, there is no E macro for errcode zero in <errno.h>,
which means that it seldom comes up here. However, reports indicate
that some platforms do have an E macro for errcode zero.
With perl, errcode zero is a bit special. Perl consistently gives
the empty string for that one, while the C strerror() may give back
something else. The easiest way to deal with that possible mismatch
is to skip this errcode.
Fixes#12798
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12799)
When generating a CRL using the "ca" utility, allow values for the
lastUpdate and nextUpdate fields to be specified using the command line
options -crl_lastupdate and -crl_nextupdate respectively.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12784)
This is a fixup of 385deae79f, which solved #12116
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12821)
add various checks for malformedness to static check_chain_extensions() in x509_vfc.c
improve error reporting of X509v3_cache_extensions() in v3_purp.c
add error reporting to x509_init_sig_info() in x509_set.c
improve static setup_dp() and related functions in v3_purp.c and v3_crld.c
add test case for non-conforming cert from https://tools.ietf.org/html/rfc8410#section-10.2
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12478)
If a path is specified with the -module option it will use this path to load the library when the provider is activated,
instead of also having to set the environment variable OPENSSL_MODULES.
Added a platform specific opt_path_end() function that uses existing functionality used by opt_progname().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12761)
ossl_pw_set_ui_method() demands that the passed |ui_method| be
non-NULL, and OSSL_STORE_attach() didn't check it beforehand.
While we're at it, we remove the passphrase caching that's set at the
library level, and trust the implementations to deal with that on
their own as needed.
Fixes#12830
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12831)
It turns out that the CONF_modules_load(conf, NULL, 0) call is just wrong.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12817)
If we initialise an EVP_MD_CTX with a legacy MD, and then reuse the same
EVP_MD_CTX with a provided MD then we end up leaking the md_data.
We need to ensure we free the md_data if we change to a provided MD.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12779)
