Move build machinery for libcrypto from libssl/crypto to libcrypto, as well
as configuration files; split manpages and .pc files between libcrypto and
libssl.
No functional change, only there to make engineering easier, and libcrypto
sources are still found in libssl/src/crypto at the moment.

ok reyk@, also discussed with deraadt@ beck@ and the usual crypto suspects.
No longer define OPENSSL_NO_EC_NISTP_64_GCC_128 on amd64; requested by djm
Crank libcrypto minor (addition of BN_consttime_swap and CRYPTO_memcmp)
and libssl major (ssl_check_clienthello_tlsext split into two functions)
Move undocumented internal OPENSSL_DIR interface from libcrypto to libssl,
so that libssl no longer need to access the non-external headers of libcrypto
to build.
No library bump, riding upon the recent update.
Do not install e_os.h, it is not an external header and should not be used
by anything in userland.
Don't edit on cvs. 23.1 as intended.
Cope with the removal of openssl/symhacks.h
Don't bother compiling files which end up containing
  #if OPENSSL_SYS_NOTYOURS
  <whole file>
  #endif
revert 1.2 and define OPENSSL_NO_EC_NISTP_64_GCC_128 again, it has a downside
(breaks ssh ecdsa keys)
Replace the old OpenSSL PRNG by direct use of arc4random_buf(), keeping the
existing RAND interfaces unchanged.

All interfaces allowing external feed or seed of the RNG (either from a file
or a local entropy gathering daemon) are kept for ABI compatibility, but are
no longer do anything.

While the OpenSSL PRNG was required 15+ years ago when many systems lacked
proper entropy collection, things have evolved and one can reasonably assume
it is better to use the kernel (system global) entropy pool rather than trying
to build one's own and having to compensate for thread scheduling...

<RANT>
Whoever thought that RAND_screen(), feeding the PRNG with the contents of the
local workstation's display, under Win32, was a smart idea, ought to be banned
from security programming.
</RANT>

ok beck@ deraadt@ tedu@
As we now remove it permanently, we no longer need NO_WINDOWS_BRAINDEATH
as a build time option...
ok deraadt@ miod@
Send the rotIBM stream cipher (ebcdic) to Valhalla to party for eternity
with the bearded ones...
some API's that nobody should be using will dissapear with this commit.
remove FIPS mode support. people who require FIPS can buy something that
meets their needs, but dumping it in here only penalizes the rest of us.
ok beck deraadt
Just like every web browser expands until it can read mail, every modular
library expands until it has its own dlfcn wrapper, and libcrypto is no
exception.

Remove the non-dlfcn DSO methods.

This causes public DSO_METHOD_{beos,dl,vms,win32} to disappear (major bump
coming soon). Note that portable software ought to use DSO_METHOD_openssl
instead of picking the backend directly (which makes one wonder why the
backends are exposed, as it is unlikely that more than one can work on
your system).

ok beck@ deraadt@
The NO_ASN1_OLD define was introduced in 0.9.7, 8 years ago, to allow for
obsolete (and mostly internal) routines to be compiled out.

We don't expect any reasonable software to stick to these interfaces, so better
clean up the view and unifdef -DNO_ASN1_OLD.

The astute reader will notice the existence of NO_OLD_ASN1 which serves a
similar purpose, but is more entangled. Its time will come, soon.
Crank major for libcrypto and libssl; more symbol removals to occur during the
next few moments, don't rush your update.
Requested by deraadt@
12 years ago, old_des.h was used to provide compatibility with libdes.
The man page says "Compatibility des_ functions are provided for a short
while" and indeed even the original commit message says "The compatibility
functions will be removed in some future release, at the latest in
version 1.0." So here we are, a short while later.

Now I've only been an OpenBSD developer for 11 years, one year less than
this header has existed, but in that brief time, I've learned a thing or
two about deleting obsolete code. It doesn't delete itself. And worse,
people will continue using it until you force them onto a better path.
The more you remove Chtulhu^WVMS tentacles, the more there are
don't even pretend to build md2, seed, or jpake
ok beck deraadt
Your operating system memory allocation functions are your friend. If they
are not please fix your operating system. Replace mem.c with an API-compatible
wrapper that just calls the system functions and does not allow a one word
modification of a variable in a running shared library to turn on memory
debug functions that expose things that should not be seen.
ok tedu@