Make all scripts produce .S, make interpretation of $(CFLAGS)
pre-processor's responsibility, start accepting $(PERLASM_SCHEME).
[$(PERLASM_SCHEME) is redundant in this case, because there are
no deviataions between Solaris and Linux assemblers. This is
purely to unify .pl->.S handling across all targets.]
Reviewed-by: Richard Levitte <levitte@openssl.org>
* Perform ALPN after the SNI callback; the SSL_CTX may change due to
that processing
* Add flags to indicate that we actually sent ALPN, to properly error
out if unexpectedly received.
* clean up ssl3_free() no need to explicitly clear when doing memset
* document ALPN functions
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
This is similar to SSL_pending() but just returns a 1 if there is data
pending in the internal OpenSSL buffers or 0 otherwise (as opposed to
SSL_pending() which returns the number of bytes available). Unlike
SSL_pending() this will work even if "read_ahead" is set (which is the
case if you are using read pipelining, or if you are doing DTLS). A 1
return value means that we have unprocessed data. It does *not* necessarily
indicate that there will be application data returned from a call to
SSL_read(). The unprocessed data may not be application data or there
could be errors when we attempt to parse the records.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
This capability is required for read pipelining. We will only read in as
many records as will fit in the read buffer (and the network can provide
in one go). The bigger the buffer the more records we can process in
parallel.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
CCA8, CCA9, CCAA, CCAB, CCAC, CCAD, and CCAE are now present in
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
so remove the "as per draft-ietf-tls-chacha20-poly1305-03" note
accordingly.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
* Perform ALPN after the SNI callback; the SSL_CTX may change due to
that processing
* Add flags to indicate that we actually sent ALPN, to properly error
out if unexpectedly received.
* clean up ssl3_free() no need to explicitly clear when doing memset
* document ALPN functions
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
For config targets such as 'dist', which doesn't have a BASE template,
we still need to have a default build scheme.
Additionally, the unified Makefile template's target 'tar' wasn't
quite as flexible as the unixmake one.
Finally, .travis-create-release.sh can be somewhat simplified now that
it builds with the unified build scheme.
Reviewed-by: Matt Caswell <matt@openssl.org>
We want to preserve a couple of classic builds still, the quickest is
to change all --unified to --classic
Reviewed-by: Matt Caswell <matt@openssl.org>
Because of the unified scheme, building on different platforms is very
similar. We currently have Unix and OpenVMS on the unified scheme,
which means that a separate INSTALL.VMS is no longer needed.
Reviewed-by: Matt Caswell <matt@openssl.org>
The kinv/r fields in the DSA structure are not used by OpenSSL internally
and should not be used in general.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The numpipes argument to ssl3_enc/tls1_enc is actually the number of
records passed in the array. To make this clearer rename the argument to
|n_recs|.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Rename the have_whole_app_data_record_waiting() function to include the
ssl3_record prefix...and make it a bit shorter.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Move out most of the boiler plate code that is common between aes128-cbc
and aes128-cbc-hmac-sha1 into helper functions to improve code reuse.
Reviewed-by: Tim Hudson <tjh@openssl.org>
The _hidden_* variables were being created on-the-fly. It is better to
create them once up front during bind to avoid any potential race
conditions.
Reviewed-by: Tim Hudson <tjh@openssl.org>
We had the function EVP_CIPHER_CTX_cipher_data which is newly added for
1.1.0. As we now also need an EVP_CIPHER_CTX_set_cipher_data it makes
more sense for the former to be called EVP_CIPHER_CTX_get_cipher_data.
Reviewed-by: Tim Hudson <tjh@openssl.org>
The new pipeline code added a new function
EVP_CIPHER_CTX_set_cipher_data(). Add documentation for this and the
existing EVP_CIPHER_CTX_cipher_data() function.
Reviewed-by: Tim Hudson <tjh@openssl.org>
We used to use the wrec field in the record layer for keeping track of the
current record that we are writing out. As part of the pipelining changes
this has been moved to stack allocated variables to do the same thing,
therefore the field is no longer needed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
A previous commit added the SSL_has_pending() function which provides a
method for knowing whether OpenSSL has buffered, but as yet unprocessed
record data.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Previously s_client and s_server relied on using SSL_pending() which does
not take into account read_ahead. For read pipelining to work, read_ahead
gets set automatically. Therefore s_client and s_server have been
converted to use SSL_has_pending() instead.
Reviewed-by: Tim Hudson <tjh@openssl.org>
This is similar to SSL_pending() but just returns a 1 if there is data
pending in the internal OpenSSL buffers or 0 otherwise (as opposed to
SSL_pending() which returns the number of bytes available). Unlike
SSL_pending() this will work even if "read_ahead" is set (which is the
case if you are using read pipelining, or if you are doing DTLS). A 1
return value means that we have unprocessed data. It does *not* necessarily
indicate that there will be application data returned from a call to
SSL_read(). The unprocessed data may not be application data or there
could be errors when we attempt to parse the records.
Reviewed-by: Tim Hudson <tjh@openssl.org>
This capability is required for read pipelining. We will only read in as
many records as will fit in the read buffer (and the network can provide
in one go). The bigger the buffer the more records we can process in
parallel.
Reviewed-by: Tim Hudson <tjh@openssl.org>
With read pipelining we use multiple SSL3_RECORD structures for reading.
There are SSL_MAX_PIPELINES (32) of them defined (typically not all of these
would be used). Each one has a 16k compression buffer allocated! This
results in a significant amount of memory being consumed which, most of the
time, is not needed. This change swaps the allocation of the compression
buffer to be lazy so that it is only done immediately before it is actually
used.
Reviewed-by: Tim Hudson <tjh@openssl.org>