Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Lan

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)

show more ...

Introduce hash thunking functions to do proper casting

ubsan on clang17 has started warning about the following undefined
behavior:

crypto/lhash/lhash.c:299:12: runtime error: c

Introduce hash thunking functions to do proper casting

ubsan on clang17 has started warning about the following undefined
behavior:

crypto/lhash/lhash.c:299:12: runtime error: call to function err_string_data_hash through pointer to incorrect function type 'unsigned long (*)(const void *)'
[...]/crypto/err/err.c:184: note: err_string_data_hash defined here
#0 0x7fa569e3a434 in getrn [...]/crypto/lhash/lhash.c:299:12
#1 0x7fa569e39a46 in OPENSSL_LH_insert [...]/crypto/lhash/lhash.c:119:10
#2 0x7fa569d866ee in err_load_strings [...]/crypto/err/err.c:280:15
[...]

The issue occurs because, the generic hash functions (OPENSSL_LH_*) will
occasionaly call back to the type specific registered functions for hash
generation/comparison/free/etc, using functions of the (example)
prototype:

[return value] <hash|cmp|free> (void *, [void *], ...)

While the functions implementing hash|cmp|free|etc are defined as
[return value] <fnname> (TYPE *, [TYPE *], ...)

The compiler, not knowing the type signature of the function pointed to
by the implementation, performs no type conversion on the function
arguments

While the C language specification allows for pointers to data of one
type to be converted to pointers of another type, it does not
allow for pointers to functions with one signature to be called
while pointing to functions of another signature. Compilers often allow
this behavior, but strictly speaking it results in undefined behavior

As such, ubsan warns us about this issue

This is an potential fix for the issue, implemented using, in effect,
thunking macros. For each hash type, an additional set of wrapper
funtions is created (currently for compare and hash, but more will be
added for free/doall/etc). The corresponding thunking macros for each
type cases the actuall corresponding callback to a function pointer of
the proper type, and then calls that with the parameters appropriately
cast, avoiding the ubsan warning

This approach is adventageous as it maintains a level of type safety,
but comes at the cost of having to implement several additional
functions per hash table type.

Related to #22896

Reviewed-by: Sasa Nedvedicky <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23192)

show more ...

All lh_stats functions were deprecated in 3.1

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale

All lh_stats functions were deprecated in 3.1

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22247)

show more ...

Change all references to OpenSSL 3.1 to OpenSSL 3.2 in the master branch

3.1 has been decided to be a FIPS 140-3 release, springing from the branch
openssl-3.0, and the master branch to

Change all references to OpenSSL 3.1 to OpenSSL 3.2 in the master branch

3.1 has been decided to be a FIPS 140-3 release, springing from the branch
openssl-3.0, and the master branch to continue with the development of
OpenSSL 3.2.

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19350)

show more ...

Add deprecation macro for 3.1 and deprecate OPENSSL_LH_stats

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/op

Add deprecation macro for 3.1 and deprecate OPENSSL_LH_stats

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17937)

show more ...

Header file cleanup for C++20 header-units

C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- t

Header file cleanup for C++20 header-units

C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- they do not require previously-included headers to provide typedefs
and what not.

This addresses 2 problems discovered when using clang modules (as a
proxy for C++20 header-units).

a) Some headers that pay attention to OPENSSL_NO_STDIO to determine
whether to declare certain FILE*-taking functions do not #include
<stdio.h> themselves, relying on their includer already having done
that. That breaks the above mentioned encapuslation requirement.
Fixed by conditionally including stdio.h in those headers. I chose to
always include stdio.h in such headers, even when they included
another such header that transitively included stdio. That way they
do not rely on an artifact of that intermediate header's behaviour.

b) Some headers have #includes inside 'extern "C" { ... }' regions.
That has a bad code-smell, but GCC and clang have extensions to permit
it with implementation-defined effects. Clang needs annotation on the
included files to know that they themselves are entirely inside a
similar region. GCC behavesq as-if there's an extern "C++" region
wrapping the included header (which must therefore wrap its contents
in extern "C", if that is what it wants. In effect the includer's
extern "C" region is just misleading. I didn't audit all the headers
for this, only those I noticed when addressing #a.

\#a is necessary to build the headers as a set of clang-modules. #b
is not necessary, but as I mentioned, avoids potentially
implementation-defined behaviour.

Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18221)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15381)

Implement the ability to convert a PROPERTY_LIST to a string

We have the ability to parse a string into a PROPERTY_LIST already. Now
we have the ability to go the other way.

Rev

Implement the ability to convert a PROPERTY_LIST to a string

We have the ability to parse a string into a PROPERTY_LIST already. Now
we have the ability to go the other way.

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15242)

show more ...

Fix some missed usage of DEFINE_LHASH_OF()

PR#12860 fixed issues with the Lhash code. It replaced usage of
DEFINE_LHASH_OF() in the public headers. Unfortunately it missed a couple
o

Fix some missed usage of DEFINE_LHASH_OF()

PR#12860 fixed issues with the Lhash code. It replaced usage of
DEFINE_LHASH_OF() in the public headers. Unfortunately it missed a couple
of instances.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13274)

show more ...