The x509_store_add() creates X509_OBJECT wrapping either X509 or
X509_CRL. However, if you set the type to X509_LU_NONE before
X509_OBJECT_free then it skips the free on the wrapped type and just
calls OPENSSL_free on the object itself. Hence, leaking wrapped
object.
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28631)
When passing the inner content type to msg_callback,
the lowest byte of rec->type needs to be passed instead
of directly passing the rec->type otherwise the value is
incorrect on Big Endian platforms.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28627)
FreeBSD also added elf_aux_info() to the 11 branch and was shipped
with 11.4.
03444a7d43
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28581)
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/28624)
The put_str() helper of the internal ossl_property_list_to_string()
function failed to correctly check the remaining buffer length in a
corner case in which a property name or string value needs quoting,
and exactly one byte of unused space remained in the output buffer.
The only potentially affected calling code is conditionally compiled
(disabled by default) provider "QUERY" tracing that is executed only
when also requested at runtime. An initial fragment of the property
list encoding would need to use up exactly 511 bytes, leaving just 1
byte for the next string which requires quoting. Bug reported by
Aniruddhan Murali (@ashamedbit)
Noble Saji Mathews (@NobleMathews)
both from the University of Waterloo.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/28624)
This is an attempt to discouraged manual changes of generated files,
as people have done so, just to get their changes over-written next
time those files are re-generated.
Reference: https://github.com/openssl/openssl/discussions/28269
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28612)
The documentation suggested that they were always zero, while the
implementation in <openssl/opensslv.h> suggested that it could be
0xf in OpenSSL releases... which (almost) never happened because
of a bug in said implementation.
Therefore, we solidify that the status bits are indeed always zero,
at least in all OpenSSL 3 versions.
Resolves: https://github.com/openssl/project/issues/1621
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28603)
Disabling the SSL_TRACE_TEST since it caused an issue on
some cross compiles. A follow-on commit will change
the test.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28621)
this adds another release/acquire link between update_qp and
get_hold_current_qp via the reader_idx because the current
one which is based on the qp users count is only preventing
a race condition, but does not help when the reader acquires
the next qp.
Fixes#27267
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28585)
This reverts commit dc5cd6f70a "rsa: expose pairwise consistency test API",
that has introduced ossl_rsa_key_pairwise_test() function, as the only user
has been removed in 7f7f75816f "import pct: remove import PCTs for most
algorithms".
Complements: 7f7f75816f "import pct: remove import PCTs for most algorithms"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28557)
The cipher protocol ID, the return type of SSL_CIPHER_get_protocol_id,
is uint16_t and correctly described in docs to be 2 bytes, however the
function signature on the same page incorrectly pointed to it being
uint32_t, which is 4 bytes.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28523)
Make SSL Trace to display the name of the MLKEM512, MLKEM768,
MLKEM1024 and SecP384r1MLKEM1024 groups.
Fixes#28476
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28499)
If the option is specified it will now implicitly enable peer verification.
The s_client command was already behaved this way, so
s_server was updated to match the behavior of s_client.
Fixes#15134
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28445)
Also refine RETURN VALUES.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28393)
We seem to be using a lot of preprocessor gymnastics to avoid
having duplicate cases in a case statement depending on what
the host system defines these values to. We should not care.
If we don't bother with the case statement this becomes
easier to follow.
While we are here, pick up the reccomended windows2 values
that correspond with the POSIX values we already have
in here that we believe are "non-fatal", and condition
the codes to use on being windows or something POSIX.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28344)
While PCT on import has been removed for DH, EC, RSA, and SLH-DSA,
ECX seems to be overlooked. Correct that omission.
Complements: 7f7f75816f "import pct: remove import PCTs for most algorithms"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28573)
The error label returned success (1) even on failure. Make it return failure (0) instead.
Fixes#28562
CLA: trivial
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28576)
Coverity notices it could overflow, since we don't use this
don't bother returning it
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28553)
If we have a comparison function, and the array was sorted,
check to see if we are inserting in the correct location.
if so do not clear is_sorted.
This allows for element locations found with OPENSSL_sk_find_ex
to be used to insert elements in the correct location and preserve
the sorting order without the need to sort the stack again.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28533)
"old" was never assigned anything and the first
assignment to "*iterations" in the loop was superfluous.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28574)
Matt noticed "It's kind of weird that we are forced to call sort on
a newly created and empty stack. It feels like an empty stack should
have the "sorted" flag by default on creation"
I am incluined to agree. This change ensures tht empty or 1 element
stacks are marked as sorted, as per the existing comment in the
file.
Since this involved changing the various duplication routines to
also ensure that sorted was preserved for such stacks, I also
noticed the duplication code was largely duplicated. I
took the opportunity to deduplicate the duplication code while
making these changes.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28509)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28469)
Fixes#27984
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28098)
This function fails to construct a param list that includes the passed
in property query string in the param lists when allocating subordonate
algorithms.
Make sure we allow callers to pass a param list (so that providers for
subordonate algorithms can be selected), and merge those into the param
list that this function builds on its own.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
We have several composite alg usages (i.e. MAC/KDF) which pick the right
digest implementation when using an engine, but fail to get the right
one when using a provider because we don't pass the propquery in a
parameter to their instantiation.
Fix them up by constructing the appropriate parameters
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
This engine is going away (in fact they all are), so just remove the
test cases referencing this engine
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
With the removal of engines we need to handle the loader_attic test that
will fail with said removal
based on the advice of @levitte, given that we have a file: loader in
the default provider already, theres no need to test an engine thats
going away, so just remove it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
replace use of ossltest engine with provider in TLSProxy and update all
dependent tests
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
Use the new ossltest provider rather than the ossltest engine
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
Replace ossltest engine with ossltest provider in test_rand
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
Part of the effort to remove engines creates a problem for our test
suite, in that we have a large number of tests that rely on the use of a
test engine (ossltest), which implements the aes-128-cbc, aes-128-gcm,
aes-128-cbc-hmac-sha1 ciphers, several digests and a random number
generator to produce predictable outputs for the purposes of doing
testing against known values.
Since we're getting rid of engines, these tests need to be updated to
use a provider that presents the same functionality.
This commit implements that provider.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28461)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28529)
Minor formating cleanups.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28547)
Allocate table in ecp_nistz256_windowed_mul() and preComputedTable
in ecp_nistz256_mult_precompute() using OPENSSL_aligned_alloc_array() call
instead of OPENSSL_malloc with a 64-byte slack and manual pointer alignment
adjustement.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
There is little need to support alignments larger than a page size,
and the open-coded OPENSSL_aligned_alloc() implementation implements
that support in quite wasteful manner, so it is better just to limit
the maximum supported alignment explicitly. The value of 65536
has been chosen so it is architecture-agnostic and is no less than page sizes
used in commonly occurring architectures (and also it is a pretty number).
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
While posix_memalign() is generally not expected to fail, we can always use
the internal aligned alloc implementation to ensure that any
OPENSSL_aligned_malloc failure is indeed fatal and does not require
a fallback.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
Factor the open-coded aligned allocation implementation in a separate
file and use it instead of just returning NULL in CRYPTO_aligned_alloc
implementation in the FIPS provider.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
Originally, CRYPTO_aligned_alloc() returned NULL if OpenSSL was built
with OPENSSL_SMALL_FOOTPRINT defined, which is a weird place for such
a consideration; moreover it means that every caller requires to
implement some form of a fallback (and manually over-allocate
and then align the returned memory if the alignment is a requirement),
which is counter-productive (and outright ridiculous in environments
with posix_memalign() available). Move the OPENSSL_SMALL_FOOTPRINT
consideration to the only current caller and update the documentation
and tests accordingly.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
While the commit 648803a17e "crypto/mem.c: don't use aligned_alloc
in CRYPTO_aligned_alloc" removed the aligned_alloc() usage
along with its overly onerous requirements, its author failed to update
the documentation accordingly. Correct that omission by removing
the requirement from the DESCRIPTION and adding a relevant mention
in HISTORY.
Complements: 648803a17e "crypto/mem.c: don't use aligned_alloc in CRYPTO_aligned_alloc"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)