Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21519)
When decoding 0 as the selection means to decode anything
you get.
However when exporting and then importing the key data 0 as
selection is not meaningful.
So we set it to OSSL_KEYMGMT_SELECT_ALL to make the export/import
function export/import everything that we have decoded.
Fixes#21493
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21519)
This is already correct in the rsa_kmgmt.c but other
implementations are wrong.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21519)
Implement the two requirements about limiting closing transmission size to
no more than thrice the received size.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21429)
This should extend the range of possible results.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21429)
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21636)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21579)
per request.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21595)
CLA: trivial
Code that includes applink.c can now define APPLINK_NO_INCLUDES to suppress the include preprocessor lines in that file. This might be needed if, for example, applink.c is being included into a source file that will be compiled to reference a C library built using different calling conventions. (Example: Open Watcom.)
This pull request is intended to replace an identical pull request that I screwed up.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21595)
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21608)
We add an additional loop around test_quic_write_read() to repeat the
test but using a session obtained from the initial iteration to confirm
that we can successfully resume the session.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21591)
If we shutdown the QUIC connection then we should mark the underlying
TLS SSL object as shutdown as well. Otherwise any sessions are considered
unusable for resumption.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21591)
There may be post-handshake messages to process so make sure we keep
ticking things even if the handshake has finished. We do this simply by
calling SSL_read(). There should never be app data to read but we will
process any handshake records we encounter.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21591)
If the request comes in in multiple chunks properly keep tract of where
we are.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21578)
s_client calls SSL_has_pending() even before the connection has been
established. We expect it to return 0 in this case and not put any errors
on the stack.
We change things so that SSL_has_pending() always returns 0 if there is
no stream available.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21578)
A call to SSL_write() with a zero length buffer should still advance the
handshake. Applications (including s_client) may rely on this.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21578)
Check that if one endpoint is sending data faster than its peer can handle
then we eventually see back pressure.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21368)
We must not ask for a password when attempting to read parameters.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
The PEM_read_bio_Parameters[_ex] function does not have the capability
of specifying a password callback. We should not use the fallback password
callback in this case because it will attempt to send a prompt for the
password which might not be the correct thing to do. We should just not
use a password in that case.
Fixes#21588
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
We're always supposed to add the fallback "unsupported" error if we don't
have anything better. However in some cases this wasn't happening because
we were incorrectly setting "flag_construct_called" - even though the
construct function had failed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
msblob only decodes public/private keys (not just params).
pvk only decodes private keys.
If the requested selection doesn't intersect with the above then don't
consider those decoders.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
In the definition of the latest revised LoongArch64 vector instruction manual,
it is clearly pointed out that the undefined upper three bits of each byte in
the control register of the vshuf.b instruction should not be used, otherwise
uncertain results may be obtained. Therefore, it is necessary to correct the
use of the vshuf.b instruction in the existing vpaes-loongarch64.pl code to
avoid erroneous calculation results in future LoongArch64 processors.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21530)
Now the default is linux-generic32, it's not good for loongarch64.
We can also test if the assembler supports vector instructions here and
disable asm if not.
Closes#21340.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21510)
Always report "<algo> ops in <time>", instead of "<algo>'s in <time>" or
similar. Avoid the use of apostrophes and/or plural with algorithm names.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21383)
While RSA encrypt/decrypt and sign/verify are basically the same mod-expo
operations, the speed of the operation may still differ, due to different
padding, as well as the use of implicit rejection for RSA decrypt.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21383)
Also fixes a similar regression in X509_VERIFY_PARAM_add0_table().
Commit 38ebfc3 introduced a regression in 3.0.6 that changed the return
value of the two functions above from 1 on success to the number of entries
in the stack. If there are more than one entry then this is a change in
behaviour which should not have been introduced into a stable release.
This reverts the behaviour back to what it was prior to the change. The code
is slightly different to the original code in that we also handle a possible
-1 return value from the stack push function. This should never happen in
reality because we never pass a NULL stack as a parameter - but for the sake
of robustness we handle it anyway.
Note that the changed behaviour exists in all versions of 3.1 (it never had
the original version). But 3.1 should be fully backwards compatible with 3.0
so we should change it there too.
Fixes#21570
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21576)
