MAP_INHERIT_ZERO anymore.  This restores arc4random's previous
behavior where fork children would mix in some randomness from the
parent process.
New behavior noticed by deraadt
ok deraadt, tedu

The extra argument doesn't hurt genuine atexit handlers and this fixes a
bug where we didn't provide the argument (effectively passing garbage) for
functions registered with __cxa_atexit in the main executable.
Pointed out by Dmitriy Ivanov <dimitry@google.com> and Elliott Hughes
<enh@google.com>.
ok matthew@

Now instead of calling getpid() each time a user invokes arc4random(),
we're able to rely on the kernel zero'ing out the RNG state if the
process forks.
ok deraadt, djm

discussion with matthew

buffersize is enforced strictly, this supplies sufficient entropy
payload to act as seed material.  Discourage general use of this
API, but lock down this function name as the go-to for userland
PRNG seeding.  Improve documentation.
ok miod matthew

of sysctl().  Mark it with XXX while we consider.

call abort().
this direction discussed at length with miod beck tedu matthew etc

I accepted that he's right (again) to seperate this out from heavy
sysctl API and this will simply a variety of things.  Functionname
is not used by anyone in the ports tree, so we guess we can use it.
Shocking that no application has a function called this.
ok matthew & others who pushed him to start this early on

ok deraadt, jmc, tedu

behavior for certain inputs.  From NetBSD.  OK tedu@

ok beck

From inframare at arachnogoat dot com; OK deraadt@ sthen@

collateral damage.
The syncronous nature of this mechanism has hampered performance for
symmetric crypto relative to brute-force cpu. The assymetric crypto
support never really materialized in drivers.
So abandon the complexity.
ok tedu beck mikeb
some disagrement from djm but if he wants to test /dev/crypto ciphers
he should do it without this this gigantic API in the way

ok aja@ dcoppa@

reported by Scott McEachern <scott@blackstaff.ca>
ok deraadt@ and todd@

found while building portable OpenNTPD
ok henning@

ok espie

of the intel RDRAND instruction.  Consensus was RDRAND should probably
only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to
RDRAND?  Yep.  Guess which applications are using this support?  Not
even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss.
ok kettenis

From Fritjof Bornebusch.

opensslconf.h is just a dummy, we're lightyears away from working userspace.
ok deraadt@

ok landry@ ajacoutot@

ok deraadt@ millert@

ok beck

freed chunk is actually freeable immediately. catch more errors.
hints/ok otto

While there, sort headers.
ok tedu@

ok miod

more #ifdefs and a new source file that contains a single function.
Nuke the #if 0 code that is now a macro and move the single function in
evp_acnf.c to c_all.c, which is where the other code lives. While here,
tidy evp.h slightly, remove an unnecessary #ifdef __OpenBSD__ and nuke
a comment that is now a lie.
ok miod@

Langley's Chromium OpenSSL patches.
ok miod@

implementations. This largely pulls in Adam Langley's AEAD patches from
Chromium's OpenSSL.
ok miod@

required. try to document this fact and some of the history.
with feedback from deraadt guenther millert

implementation.
ok miod@

probably more 32-bit platforms).
Problem noticed by tobiasu@; ok tobiasu@ dtucker@ sthen@ benno@

of 64-bit data, and only used by DTLS, to libssl where it belongs.
Remove pqueue_print() which is a debugging interface and serves no useful
purpose, except for the regress test, which grows its own pqueue_print()
routine.
Bump libcrypto major and libssl minor.
WARNING: do not update your tree right now, more changes are coming, which
will ride the libcrypto major bump.

while changing things, add a crypt_checkpass wrapper that handles most of
the edge cases. (not quite ready for production, though.)
ok deraadt

It's not a standard interface, so it doesn't belong in libc.
I hate duplicating the code in client programs, so do beck@, kettenis@,
schwarze@, millert@, miod@... and they agree with libutil.