We were kinda sorta using a mix of $disabled{"static-engine" and
$disabled{"dynamic-engine"} in Configure.  Let's avoid confusion,
choose one of them and stick to it.

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

An error was introduced with the setting of SHLIB in DO_GNU_SO.
A common DO_GNU_SO_COMMON that both DO_GNU_SO and DO_GNU_SO_NOCALC use
makes things clearer.

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

Because we're requiring Perl 5.10.0 and the 'parent' didn't appear
before Perl 5.10.1, we need to resort to the older parent module
declaration style, modifying @ISA.

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

On slower file systems, this makes a huge difference

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

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

GNU make will re-exec if (it thinks that) the Makefile has changed.
Just having the target Makefile seems to make it think it has, so we
end up in a look where GNU make re-execs for ever.

The fix is easy, just remove the Makefile target and have the depend
target run the recipe on its own instead of depending on Makefile.

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

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

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

is a .s).

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

Don't check for no_shared

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

They depend on this feature because they use the engine ossltest,
which is only available as a dynamic engine.

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

Until now, the engines in engines/ were only built as dynamicaly
loadable ones if shared libraries were built.

We not dissociate the two and can build dynamicaly loadable engines
even if we only build static libcrypto and libssl.  This is controlled
with the option (enable|disable|no)-static-engine, defaulting to
no-static-engine.

Note that the engines in crypto/engine/ (dynamic and cryptodev) will
always be built into libcrypto.

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

This takes us away from the idea that we know exactly how our static
libraries are going to get used.  Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.

On the other hand, we also have greater control of when the shared
library cflags.  They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.

With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).

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

Depending on Makefile meant that a new attempt to rebuild the Makefile
with "new" dependency data was done all the time, uncontrolled.  Better
to depend on configdata.pm, which truly only changes with reconfiguration.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Laurie <ben@openssl.org>

Also gives an error message when you gave it a parameter it didn't expect.

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

MR: #2009

One spot was forgotten.

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

Object LiBrary

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

It failed to remove lingering Makefile.new

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

It was turning off output again in two place where it should have
turned it on.

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

Reviewed-by: Tim Hudson <tjh@openssl.org>

Remove DSA private key code which tolerates broken implementations which
use negative integers.

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

Remove old code that handled various invalid DSA formats in ancient
software.

This also fixes a double free bug when parsing malformed DSA private keys.

Thanks to Adam Langley (Google/BoringSSL) for discovering this bug using
libFuzzer.

CVE-2016-0705

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

Adapted from BoringSSL. Added a test.

The extension parsing code is already attempting to already handle this for
some individual extensions, but it is doing so inconsistently. Duplicate
efforts in individual extension parsing will be cleaned up in a follow-up.

Reviewed-by: Stephen Henson <steve@openssl.org>

This silences the memory sanitizer. All fields were already correctly
initialized but the struct padding wasn't, causing an uninitialized read
warning.

Reviewed-by: Tim Hudson <tjh@openssl.org>

crypto.h: honor no-filenames config setting in missing cases

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Matt Caswell <matt@openssl.org>

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

So far, MingW shared libraries were named like this

  libeay32.dll + libeay32.dll.a
  ssleay32.dll + ssleay32.dll.a

That naming scheme is antiquated, a reminicense of SSLeay.  We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.

There are two factors to remember:

  - Windows libraries have no recorded SOvers, which means that the
    shared library version must be encoded in the name.  According to
    some, it's unwise to encode extra periods in a Windows file name,
    so we convert version number periods to underscores.
  - MingW has multilib ability.  However, DLLs need to reside with the
    binaries that use them, so to allow both 32-bit and 64-bit DLLs to
    reside in the same place, we add '-x64' in the name of the 64-bit
    ones.

The resulting name scheme (for SOver 1.1) is this:

  on x86:
  libcrypto-1_1.dll + libcrypto.dll.a
  libssl-1_1.dll + libssl.dll.a

  on x86_64:
  libcrypto-1_1-x64.dll + libcrypto.dll.a
  libssl-1_1-x64.dll + libssl.dll.a

An observation is that the import lib is the same for both
architectures.  Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.

As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets.  link_shlib.mingw-shared is,
however, a target separated from the cygwin one.

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

Better libclean that removes the exact files that have been built,
nothing more and nothing less.

Corrected typo

A couple of editorial changes.

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

Of course, if there are remaining files in a directory, it won't be removed.

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

Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.

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

Instead of having the installation recipe rely on special knowledge,
feed it with information, including what shared library files belong
together.  For Cygwin and Mingw, that's the .dll and its import
library .dll.a.  For Unixen, it's the shared library file name with SO
version and the one without.

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

The engine DSOs were named as if they were shared libraries, and could
end up having all sorts of fancy names:

  Cygwin: cygFOO.dll
  Mingw:  FOOeay32.dll
  Unix:   libFOO.so / libFOO.sl / libFOO.dylib / ...

This may be confusing, since they look like libraries one should link
with at link time, when they're just DSOs.

It's therefore time to rename them, and do it consistently on all
platforms:

  Cygwin & Mingw: FOO.dll
  Unix:           FOO.{so,sl,dylib,...}

Interestingly enough, the MSVC and VMS builds always did it this way.

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

Because we know for certain that the link_shlib targets are used
exclusively for shared libraries (libcrypto and libssl) and that they
must have an associated .num file, we don't need to check the library
name to produce an ld script.  Just do it unconditionally.

link_shlib.linux-shared can be simplified further, as most of it is
exactly the same as $(DO_GNU_SO) with just one variable modification.

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

Originally, the Makefile.shared targets described what they used as
input for a shared object, be it a shared library or a DSO.  It turned
out, however, that the link_o targets were used exclusively for
engines and the link_a targets were for libcrypto and libssl.

This rename fest turns and indication on the kind of input the targets
get to the intention with using them.

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

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

Then it can pass around the information where it belongs.  The
Makefile templates pick it up along with other target data, the
DSO module gets to pick up the information through
crypto/include/internal/dso_conf.h

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

- install_sw had a display of text that belongs under the install target
- previous layout installed architecture dependent files in
  dev:['prefix'.'arch'.LIB], dev:['prefix'.'arch'.EXE] and
  dev:['prefix'.'arch'.ENGINES].  Changed to dev:['prefix'.LIB.'arch'],
  dev:['prefix'.EXE.'arch'] and dev:['prefix'.ENGINES.'arch'] instead.

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

This is done with a simple file name comparison.  We could think of
something more elegant in the future.

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

Some directories weren't removed.

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

Adding uplink and applink to some builds was done by "magic", the
configuration for "mingw" only had a macro definition, the Configure
would react to its presence by adding the uplink source files to
cpuid_asm_src, and crypto/build.info inherited dance to get it
compiled, and Makefile.shared made sure applink.o would be
appropriately linked in.  That was a lot under the hood.

To replace this, we create a few template configurations in
Configurations/00-base-templates.conf, inherit one of them in the
"mingw" configuration, the rest is just about refering to the
$target{apps_aux_src} / $target{apps_obj} in the right places.

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