The passed 'pkey' already contains a library context, and the encoder
implementations should be found within the same context, so passing an
explicit library context seems unnecessary, and potentially dangerous.
It should be noted that it's possible to pass an EVP_PKEY with a
legacy internal key. The condition there is that it doesn't have a
library context assigned to it, so the NULL library context is used
automatically, thus requiring that appropriate encoders are available
through that context.
Fixes#13544
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13545)
When printing human readable info on the Thawte Strong Extranet extension
the version number could overflow if the version number == LONG_MAX. This
is undefined behaviour.
Issue found by OSSFuzz.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13452)
The X942 KDF had been modified so that it supports all optional fields - not
just the fields used by CMS.
As there are 2 types of KDF for X942 - this has been made a bit clearer
by adding an X942KDF-ASN1 alias. X942KDF-CONCAT has also been added as an
alias of X963KDF.
This work was instigated as a result of the ACVP tests optionally being
able to use keybits for the supp_pubinfo field.
Setting the parameter OSSL_KDF_PARAM_X942_USE_KEYBITS to 0 allows this
to be disabled.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13418)
Fixes#12476
Note this stopped working when ECX was swapped over to using
providers. The ECX_KEY keygen and exchange were converted, but not the ED
signing support.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
(Merged from https://github.com/openssl/openssl/pull/13508)
Tests randomisation wasn't reliably printing the seed used on failure in the CIs.
Fixes: #13572
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13573)
Previously the system guessing logic would incorrectly guess
i686-apple-darwin as the fallback for any unspecified architecture
that is a Darwin target
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13517)
CLA: trivial
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13584)
This very simple module loader is only linked with the standard C
library, so cannot and should not provide any other symbol to the
module it tries to load. It can thereby be used to verify that the
module it tries to load doesn't have any surprising dependencies when
it's supposed to be self contained.
A test recipe is added to verify the FIPS module with this loader.
Fixes#11020
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13507)
ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected
by silicon errata #1742098 [0] and #1655431 [1], respectively, where the
second instruction of a AES instruction pair may execute twice if an
interrupt is taken right after the first instruction consumes an input
register of which a single 32-bit lane has been updated the last time it
was modified.
This is not such a rare occurrence as it may seem: in counter mode, only
the least significant 32-bit word is incremented in the absence of a
carry, which makes our counter mode implementation susceptible to these
errata.
So let's shuffle the counter assignments around a bit so that the most
recent updates when the AES instruction pair executes are 128-bit wide.
[0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice
[1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13504)
Various sections of code assumed that at least one of dh or ec would be
available. We also now also need to handle cases where a provider has
a key exchange algorithm and TLS-GROUP that we don't know about.
Fixes#13536
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13549)
If OPENSSL_SMALL_FOOTPRINT was defined then the CHACHA20-POLY1305
implementation for TLS went down a different codepath that failed to
adjust the payload length to remove the tag.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13513)
Addition using the NULL pointer (even when adding 0) is undefined
behaviour. Recent versions of ubsan are now complaining about this, so
we fix various instances.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13513)
These two bodies should be grouped together anyway as the reason for
the call to BIO_flush() is to permit using BIO_set_ktls_ctrl_msg().
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13090)
When using KTLS, empty fragments sent as a mitigation for known-IV
weakenesses in TLS 1.0 are sent as writes of 0 bytes. The TLS header
and trailer are added to the empty fragment by the kernel.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13090)
The URI length was set to 80 chars, but the URI being built up may
need more space, all depending on the paths used to get to the files
that are to be loaded. If the result needs more than 80 chars, the
test will fail.
Fixed by using PATH_MAX.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13546)
ERR_get_error_line() is deprecated, and ERR_get_error_func() and
ERR_get_error_data() are removed in favor of ERR_get_error_all(),
since they pop the error record, leaving the caller with only partial
error record data and no way to get the rest if the wish.
If it's desirable to retrieve data piecemeal, the caller should
consider using the diverse ERR_peek functions and finish off with
ERR_get_error().
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13466)
If we specify no-engine then this should cascade to also mean
no-dynamic-engine. The store test was only checking whether
dynamic-engine was disabled, meaning that some tests were failing
in a no-engine build.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13502)
Also move the #define(s) for the ASN1_ITYPE_.. before their first use.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12687)
EVP_PKEY_CTX_set_dsa_ functions were only available when DSA was
enabled ('no-dsa' not configured). However, that makes it impossible
to use these functions with an engine or a provider that happens to
implement DSA. This change solves that problem by shuffling these
functions to more appropriate places.
Fixes#13529
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13530)
CLA: trivial
Reviewed-by: Matt Caswell <matt@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/13515)
d2i_RSAPrivateKey.pod is the more generic page for these deprecated
functions and provides advice and guidance on how to translate the old
style functions into new ones.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13138)
Extend the existing CHANGES.md entry with information about the
additional functions that have also been deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13138)
EVP_PKEY_set1_DH is deprecated so there is no need to test it in a
no-deprecated build.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13138)
d2i_DHparams and i2d_DHparam as well as the equivalent DHX functions are
deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13138)
The functions return a DH object and therefore need to be deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13138)
pem_read_depr_test needed to be setup in build info so that it only
exists inside an IF[{- !$disabled{'deprecated-3.0'} -}] block.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/13543)
Fixes#13057
When using an engine, there is no cipher->prov so a call to
EVP_CIPHER_CTX_set_padding() returns an error when
evp_do_ciph_ctx_setparams() is called. For the legacy path it needs to
avoid doing the call and just return 1.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13437)
This commit tries to address a locking issue in evp_pkey_reset_unlocked
which can occur when it is called from evp_pkey_downgrade.
evp_pkey_downgrade will acquire a lock for pk->lock and if successful
then call evp_pkey_reset_unlocked. evp_pkey_reset_unlocked will call
memset on pk, and then create a new lock and set pk->lock to point to
that new lock. I believe there are two problems with this.
The first is that after the call to memset, another thread would try to
acquire a lock for NULL as that is what the value of pk->lock would be
at that point.
The second issue is that after the new lock has been assigned to
pk->lock, that lock is different from the one currently locked so
another thread trying to acquire the lock will succeed which can lead to
strange behaviour. More details and a reproducer can be found in the
Refs link below.
This changes the evp_pkey_reset_unlocked to not touch the lock
and the creation of a new lock is done in EVP_PKEY_new.
Refs:
https://github.com/danbev/learning-libcrypto/blob/master/notes/issues.md#openssl-investigationtroubleshootinghttps://github.com/nodejs/node/issues/29817
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13374)
Documenting when EVP_MD_CTX_reset() is implicitly called and when
type can be set to NULL.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13402)
