cipher_hw_generic_##mode has been renamed to ossl_cipher_hw_generic_##mode.
There were a few missing renames for t4 in .inc files.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13213)
We were missing a call to SSLfatal. A comment claimed that we had already
called it - but that is incorrect.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13229)
Also, restore a behaviour change, where load_cert() would look at
stdin when the input file name is NULL, and make sure to call
load_cert_pass() with a corresponding argument where load_cert() was
used in OpenSSL 1.1.1.
Fixes#13235
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13236)
Fixes#7930
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12927)
The keydata argument of OSSL_FUNC_keymgmt_validate() should be read-only.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13201)
This removes a TODO.
This function is not needed since any place that needs to do the
conversion normally has a special case name2nid table.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13202)
The keydata argument of OSSL_FUNC_keymgmt_has() should be read-only.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13200)
This tries to fix the following link errors on aarch64 when using OpenSSL
3.0.0 alpha 6, compiling it with "no-shared" and -fPIC in CFLAGS, then
trying to use the resulting OpenSSL static libraries in the build of
elfutils, which embed libcrypto.a into libdebuginfo.so, which hides all
symbols (except the libdebuginfod ones) by default:
/opt/1A/toolchain/aarch64-v4.0.86/lib/gcc/aarch64-1a-linux-gnu/8.4.1/../../../../aarch64-1a-linux-gnu/bin/ld: /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha1-armv8.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha1-armv8.o): in function `sha1_block_data_order':
(.text+0x0): dangerous relocation: unsupported relocation
/opt/1A/toolchain/aarch64-v4.0.86/lib/gcc/aarch64-1a-linux-gnu/8.4.1/../../../../aarch64-1a-linux-gnu/bin/ld: /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-chacha-armv8.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-chacha-armv8.o): in function `ChaCha20_ctr32':
(.text+0x6c): dangerous relocation: unsupported relocation
/opt/1A/toolchain/aarch64-v4.0.86/lib/gcc/aarch64-1a-linux-gnu/8.4.1/../../../../aarch64-1a-linux-gnu/bin/ld: /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha256-armv8.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha256-armv8.o): in function `sha256_block_data_order':
(.text+0x0): dangerous relocation: unsupported relocation
/opt/1A/toolchain/aarch64-v4.0.86/lib/gcc/aarch64-1a-linux-gnu/8.4.1/../../../../aarch64-1a-linux-gnu/bin/ld: /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha512-armv8.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-sha512-armv8.o): in function `sha512_block_data_order':
(.text+0x0): dangerous relocation: unsupported relocation
/opt/1A/toolchain/aarch64-v4.0.86/lib/gcc/aarch64-1a-linux-gnu/8.4.1/../../../../aarch64-1a-linux-gnu/bin/ld: /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-poly1305-armv8.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-poly1305-armv8.o): in function `poly1305_init':
(.text+0x14): dangerous relocation: unsupported relocation
/workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-poly1305-armv8.o): in function `poly1305_emit_neon':
(.text+0x8e4): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `poly1305_emit' defined in .text section in /workdir/build/build-pack/build-pack-temporary-static-dependencies/install/lib/libcrypto.a(libcrypto-lib-poly1305-armv8.o)
In poly1305-armv8.pl, hide symbols the same way they are hidden in poly1305-x86_64.pl.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13056)
The following internal functions are affected:
ossl_do_blob_header
ossl_do_PVK_header
ossl_b2i
ossl_b2i_bio
This is reflected by moving include/internal/pem.h to include/crypto/pem.h
engines/e_loader_attic gets the source code added to it to have
continued access to those functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13195)
Also deprecate EVP_PKEY_get1_tls_encodedpoint().
The preferred alternative is EVP_PKEY_set1_encoded_public_key() and
EVP_PKEY_get1_encoded_public_key().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13105)
We do the same thing for the "get1" version. In reality this has broader
use than just TLS (it can also be used in CMS), and "encodedpoint" only
makes sense when you are talking about EC based algorithms.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13105)
Add return value for aarch64 in the init key function.
This will avoid overwriting the stream pointers of aarch64.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13133)
When the crlNumber field contains only 0-9 digits, the output is
ambiguous as to what base it's in, which can be confusing. Adding this
prefix makes it explicit that it's in hex.
CLA: trivial
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12434)
One of the x509 tests checks to make sure spurious errors don't appear on
the stack. The x509 app uses the OSSL_STORE code to load things. The
OSSL_STORE code will try various different formats - which results in
lots of failures. However those failures are typically suppressed by
OSSL_STORE unless they are interesting. OSSL_STORE thinks it knows what
kind of errors are uninteresting (ASN.1 errors) but gets confused if
upper levels of code add additional errors to the stack. This was
happening in the DSA code which confused OSSL_STORE and meant the errors
were not being suppressed properly - and hence the x509 test failed.
Interestingly this only impacts a no-dh build, because in a no-dh build
the DSA param decoder suddenly becomes the last to be tried. If it
happens earlier in the list the errors end up getting suppressed anyway.
The simplest solution is to just to remove the error from the DSA param
decoder code. It's not adding any useful information anyway.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13162)
Some DH tests are done against files generated with '-pkeyopt priv_len:224'
This parameter must of course be reproduced when creating the key with
EVP_PKEY_fromdata(), or there will be a default that's guaranteed to
differ from the key parameters on file.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13166)
The recommended private key length is a key parameter among other key
parameters, and is included in the key data transferred in an import
or export between legacy implementations and provider implementations.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13166)
The DH private key length, which is an optional parameter, wasn't
properly imported / exported between legacy and provider side
implementations.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13166)
OSSL_DECODER_CTX_set_params() and OSSL_ENCODER_CTX_set_params() would
stop as soon as a decoder / encoder instance failed, which leaves the
rest of them with a possibly previous and different value.
Instead, these functions will now call them all, but will return 0 if
any of the instance calls failed.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13156)
'git push --follow-tags' does a little too much, any spurious tag
object that the releaser have in their local repository will come
along, even though they have nothing to do with the commits being
pushed.
Therefore, we modify the instructions to show a separate and explicit
push of the release tag.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13159)
In the interest of finding out what went wrong with a test by looking
at its output, tconversion.pl is modified to take arguments in option
form, and gets an additional -prefix option that callers can use to
ensure output files are uniquely named.
Test recipes are modified to use these new options.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13147)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13136)
The security operation SSL_SECOP_TMP_DH is defined to take an EVP_PKEY
in the "other" parameter:
/* Temporary DH key */
# define SSL_SECOP_TMP_DH (7 | SSL_SECOP_OTHER_PKEY)
In most places this is what is passed. All these places occur server side.
However there is one client side call of this security operation and it
passes a DH object instead. This is incorrect according to the
definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other
locations.
Our own default security callback, and the debug callback in the apps,
never look at this value and therefore this issue was never noticed
previously. In theory a client side application could be relying on this
behaviour and could be broken by this change. This is probably fairly
unlikely but can't be ruled out.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13136)
We create a new file ssl/tls_depr.c to contain functions that need to call
deprecated APIs in libssl. This enables us to remove
OPENSSL_SUPPRESS_DEPRECATED from a number of other libssl files.
The deprecated API usage is either related to ENGINEs and is needed to
continue to support applications that use such ENGINEs. Or they are needed
to support some deprecated public libssl APIs.
One other file remains in libssl that still uses deprecated APIs: s3_cbc.c
This is needed to support the deprecated SSLv3.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13135)
This include is required for c99 on the NonStop TNS/X platform.
CLA: trivial
Fixes#13102
Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13103)
This change makes the naming more consistent, because three different terms
were used for the same thing. (The term libctx was used by far most often.)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.
The OPENSSL_CTX type stands out a little by using a different prefix.
For consistency reasons, this type is renamed to OSSL_LIB_CTX.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
These were previously added as an internal API. But since the CMS code
needs them, other code might do too.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13088)
Low level algorithm implementations have no business knowing about details
of the higher level CMS concept. This knowledge is therefore moved into the
CMS layer.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13088)
There is a large amount of CMS sepcific code in the algorithms. This is in
the wrong place and breaks layering. This code should be in the CMS layer.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13088)
There is quite a large amount of algorithm specific CMS code sitting in
the algorithm directories. However, this seems to break layering.
Algorithms really have no business knowing anything about CMS. Really it
should be the other way around. Where there is algorithm specific CMS code
it is the CMS layer that should know how to handle different algorithms.
Therefore we move this code into the CMS layer.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13088)