With bash and zsh, the trap on the 5 second read does respond, but
doesn't break out of the read.  What's worse is that it takes away the
5 second timer, and therefore has the read hang indefinitely and
(almost) unbreakable.

Having the trap do 'exit 0' after reseting the tty params has it break
out of read and continue with the configuration.

Other shells do not appear to have the issue described here, but
neither does the extra 'exit 0' appear to harm them.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Document EVP_PKEY_id() and EVP_PKEY_base_id().
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NKurt Roeckx <kurt@openssl.org>

A couple of '$(PERLASM_SCHEM' had sneaked in.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

The reason to do so is that some of the generators detect PIC flags
like -fPIC and -KPIC, and those are normally delivered in LD_CFLAGS.
Reviewed-by: NRich Salz <rsalz@openssl.org>

When passing down values to Makefile.shared, do so with single quotes
as much as possible to avoid having the shell create a mess of quotes.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared".  The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.

To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS.  That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.

Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: NRich Salz <rsalz@openssl.org>

ENGINE_cleanup calls CRYPTO_free_ex_data and therefore,
CRYPTO_cleanup_all_ex_data - which cleans up the method pointers - must
run after ENGINE_cleanup.

Additionally, don't needlessly initialize the EX_CALLBACKS stack during
e.g. CRYPTO_free_ex_data. The only time this is actually needed is when
reserving the first ex data index. Specifically, since sk_num returns -1
on NULL input, the rest of the code already handles a NULL method stack
correctly.
Reviewed-by: NRich Salz <rsalz@openssl.org>

With help from Viktor.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

ccache + clang produces a false strcmp warning, see
https://llvm.org/bugs/show_bug.cgi?id=20144

Since this only happens with ccache and --strict-warnings, and
only with certain versions of glibc / clang, disabling
ccache is a reasonable short-term workaround.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

While insignificant on Unix like systems, this is significant on
systems like VMS.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>

It turns out that different sed implementations treat -i differently
to cause issues.  make it simpler by avoiding it entirely and give
perl the trust to be consistent enough.
Reviewed-by: NRich Salz <rsalz@openssl.org>

That doesn't change even to make a dummy to hide its unavailability.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

On Windows we call WSAGetLastError() to find out the last error that
happened on a socket operation. We use this to find out whether we can
retry the operation or not. You are supposed to call this immediately
however in a couple of places we logged an error first. This can end up
making other Windows system calls to get the thread local error state.
Sometimes that can clobber the error code, so if you call WSAGetLastError()
later on you get a spurious response and the socket operation looks like
a fatal error.

Really we shouldn't be logging an error anyway if its a retryable issue.
Otherwise we could end up with stale errors on the error queue.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

verified that build succeeds without the extra define
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Fix no-blake2 for Windows classic build
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

The issue is demonstrated as follows:

  On Linux:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | sed -e 's/ \/\(\\.\|[^ ]\)*//g'
    : foo.h bar.h

  On MacOS X:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | sed -e 's/ \/\(\\.\|[^ ]\)*//g'
    : foo.husr/include/stddef.h bar.h

Perl is more consistent:

  On Linux:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | perl -pe 's/ \/(\\.|[^ ])*//g;'
    : foo.h bar.h

  On MacOS X:

    $ echo ': foo.h /usr/include/stddef.h bar.h' | perl -pe 's/ \/(\\.|[^ ])*//g;'
    : foo.h bar.h
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

They are not numbers in the machine byte order.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

If pre-processor failed, an empty .s file could be left behind,
which could get successfully compiled if one simply re-ran make
and cause linking failures. Not anymore. Remove even intermediate .S
in case of pre-processor failure.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Running test_ssl with HARNESS_VERBOSE results in lots of spurious warnings
about an inability to load the CT config file. This fixes it.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Issue identified on Solaris by Erik Forsberg <erik@efca.com>
Reviewed-by: NRich Salz <rsalz@openssl.org>