We don't want to hold a read lock when calling a user supplied callback.
That callback could do anything so the risk of a deadlock is high.
Instead we collect all the names first inside the read lock, and then
subsequently call the user callback outside the read lock.
Fixes#14225
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14250)
Without this, a provider has no way to know that an application
has finished with the array it returned earlier. A non-caching provider
requires this information.
Fixes#12974
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12974)
The functions are not needed and require returning octet ptr parameters
from providers that would like to support them which complicates provider
implementations.
Fixes#12985
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14279)
Add an argument to PROVIDER_try_load() that permits a provider to be
loaded without changing the fallback status. This is useful when an
additional provider needs to be loaded without perturbing any other setup.
E.g. adding mock providers as part of unit testing.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13652)
This does what was previously done by looking at pctx->pmeth->pkey_id,
but handles both legacy and provider side contexts, and is supposed to
become a replacement for the old way.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13913)
The OSSL_CORE_MAKE_FUNC macro has been added since 1.1.1 and is
undocumented. However it is not intended for application use and so we
document it as "reserved".
Fixes#13192
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14232)
This macro was added since 1.1.1 and was undocumented.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14232)
This macro was added since 1.1.1 but had no associated documentation.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14232)
The function OPENSSL_LH_flush() was added since 1.1.1 and was
undocumented. We also add documentation for some other OPENSSL_LH_*()
functions at the same time.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14232)
Adding the EVP_PKEY_param_check_quick() reminded me that there are also
partial checks for public keys as part of SP800-56A for FFC (DH named safe
prime groups) and ECC. The code was mainly already there and just needed
to be plumbed into the validate methods.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14206)
When the string "ABCDEFGH" is passed, what's considered its data, this?
{ 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H' }
or this?
{ 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', '\0' }
If it's passed as a pass phrase, should the terminating NUL byte be
considered part of the pass phrase, or not?
Our treatment of OSSL_PARAMs with the data type OSSL_PARAM_UTF8_STRING
set the length of the string to include the terminating NUL byte,
which is quite confusing. What should the recipient of such a string
believe?
Instead of perpetuating this confusion, we change the assumption to
set the OSSL_PARAM to the length of the string, not including the
terminating NUL byte, thereby giving it the same value as a strlen()
call would give.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14168)
Additional renames done in encoder and decoder implementation
to follow the style.
Fixes#13622
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14155)
For consistency with `OSSL_DECODER.pod`, and `man-pages(7)`, the `NOTES`
section is moved at the end of the file.
According to `man-pages(7)` the recommended section order is:
> NAME
> SYNOPSIS
> CONFIGURATION [Normally only in Section 4]
> DESCRIPTION
> OPTIONS [Normally only in Sections 1, 8]
> EXIT STATUS [Normally only in Sections 1, 8]
> RETURN VALUE [Normally only in Sections 2, 3]
> ERRORS [Typically only in Sections 2, 3]
> ENVIRONMENT
> FILES
> VERSIONS [Normally only in Sections 2, 3]
> CONFORMING TO
> NOTES
> BUGS
> EXAMPLE
> SEE ALSO
This commit does not attempt to fix the order in all pages but focuses
only on `OSSL_ENCODER` which has a "twin" man page in `OSSL_DECODER`,
making the inconsistent section order quite jarring.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13932)
This commit fixes the DECSCRIPTION section of doc/man3/OSSL_ENCODER.pod,
where `OSSL_ENCODER_properties` was incorrectly referred to as
`OSSL_ENCODER_provider`.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13932)
Add a handler for EBUSY sendfile error in addition to
EAGAIN. With EBUSY returned the data still can be partially
sent and user code has to be notified about it, otherwise it
may try to send data multiple times.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13716)
The functions are obsolete aliases for BN_rand() and BN_rand_range()
since 1.1.0.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14080)
Fixes#14041 and additional bugs discovered by the newly created
tests.
This patch:
- Introduces support for 0x prefixed integers
- Fixes parsing of negative integers (negative numbers were
shifted by -2)
- Fixes ability to parse maximal unsigned numbers ("too small
buffer" error used to be reported incorrectly)
- Fixes a memory leak when OSSL_PARAM_allocate_from_text fails
leaving a temporary BN allocated
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14093)
The existing names such as EVP_PKEY_param_fromdata_settable were a bit
confusing since the 'param' referred to key params not OSSL_PARAM. To simplify
the interface a 'selection' parameter will be passed instead. The
changes are:
(1) EVP_PKEY_fromdata_init() replaces both EVP_PKEY_key_fromdata_init() and EVP_PKEY_param_fromdata_init().
(2) EVP_PKEY_fromdata() has an additional selection parameter.
(3) EVP_PKEY_fromdata_settable() replaces EVP_PKEY_key_fromdata_settable() and EVP_PKEY_param_fromdata_settable().
EVP_PKEY_fromdata_settable() also uses a selection parameter.
Fixes#12989
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14076)
These functions are modified to use EVP_PKEY_set_octet_string_param()
and EVP_PKEY_get_octet_string_param() instead of evp_keymgmt_set_params()
and evp_keymgmt_get_params().
To accomplish this fully, EVP_PKEY_get_octet_string_param() is changed
slightly to populate |*out_sz| with the return size, even if getting
the params resulted in an error.
We also modify EVP_PKEY_get_utf8_string_param() to match
EVP_PKEY_get_octet_string_param()
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14056)
The checks of the type of EVP_PKEY were from before we had the macro
evp_pkey_is_provided().
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14056)
They were calling evp_keymgmt_set_params() directly. Those calls are
changed to go through EVP_PKEY_set_params().
We take the opportunity to constify these functions. They have to
unconstify internally for the compiler to stop complaining when
placing those pointers in an OSSL_PARAM element, but that's still
better than forcing the callers to do that cast.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14056)
They are still used internally in legacy code.
Also fixed up some minor things in EVP_DigestInit.pod
Fixes: #14003
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14008)
This commit attempts to fix the an issue when generating a key of type
EVP_PKEY_RSA_PSS. Currently, EVP_PKEY_CTX_set_rsa_keygen_bits will
return -1 if the key id is not of type EVP_PKEY_RSA. This commit adds
EVP_PKEY_RSA_PSS to also be accepted.
The macro EVP_PKEY_CTX_set_rsa_pss_keygen_md si converted into a
function and it is now called in legacy_ctrl_to_param.
Fixes#12384
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13099)
OSSL_PARAM_allocate_from_text() converted text values to UTF-8
OSSL_PARAMs with a simple strncpy(). However, if the text is EBCDIC,
that won't become UTF-8. Therefore, it's made to convert from EBCDIC
to ASCII on platforms where the native character encoding is the
former.
One might argue that the conversion should be the responsibility of
the application. However, this is a helper function, and the calling
application can't easily know what sort of OSSL_PARAM the input values
are going to be used for.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13961)
The client-side cert verification callback function may not only return
as usual for success or 0 for failure, but also -1,
typically on failure verifying the server certificate.
This makes the handshake suspend and return control to the calling application
with SSL_ERROR_WANT_RETRY_VERIFY.
The app can for instance fetch further certificates or cert status information
needed for the verification.
Calling SSL_connect() again resumes the connection attempt
by retrying the server certificate verification step.
This process may even be repeated if need be.
The core implementation of the feature is in ssl/statem/statem_clnt.c,
splitting tls_process_server_certificate() into a preparation step
that just copies the certificates received from the server to s->session->peer_chain
(rather than having them in a local variable at first) and returns to the state machine,
and a post-processing step in tls_post_process_server_certificate() that can be repeated:
Try verifying the current contents of s->session->peer_chain basically as before,
but give the verification callback function the chance to pause connecting and
make the TLS state machine later call tls_post_process_server_certificate() again.
Otherwise processing continues as usual.
The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod
and SSL_want.pod.
This adds two tests:
* A generic test in test/helpers/handshake.c
on the usability of the new server cert verification retry feature.
It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto-
generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored).
* A test in test/sslapitest.c that demonstrates the effectiveness of the approach
for augmenting the cert chain provided by the server in between SSL_connect() calls.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13906)
