ok reyk@

Should improve sparc64 and other be archs. ok matthew@ miod@

ok miod@

- use <>

malloc can, as always, be emulated via realloc(NULL).
ok deraadt

ok henning@

ok henning@

ok deraadt@ guenther@

already manually disabled).
ok deraadt@

value to use for the strerror() message as an argument.  Originally from
FreeBSD 3.0
Patch from Steffen Nurpmeso (sdaoden (at) gmail.com) with minor tweaks.

the _* functions outside libc

Like calloc(), except without the cleared-memory gaurantee
ok beck guenther, discussed for more than a year...

From Ben Cornett (ben (at) lantern.is)

ok deraadt@

APIs that pass times as longs will have to change at some point...
Bump major on both libcrypto and libssl.
ok tedu@

very rarely if ever needed any more. we should not trick people into
thinking they are impoving sth doing so, it's rather the opposite
these days.
ok claudio

carp, rpc or nfs traffic in the initial ruleset active during network
startup for a short time (or a much longer time if /etc/pf.conf is
screwed up). ok phessler

non-dangerous use functions is difficult.
ok guenther

but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@
ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

are still some 3rd-party code using it, and fixing them is not trivial.
As an excuse gift, the memory leaks on failure in resurrected a_set.c have
been fixed.

ok deraadt

ok deraadt.

"commit the switch now" espie@  "go for it" deraadt@
See the apropos(1) manual for a description of what's new.
On machines where you want the full functionality,
run "sudo makewhatis" and put "MAKEWHATISARGS=' '" into weekly.local(8).
Otherwise, when upgrading via source, run "sudo makewhatis -Q".

supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had
to be convoluted enough for the compiler not to recognize that this was
actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse()
is beyond me. Did someone not trust the C obfuscation?

fragments, to ease maintainance, and see through the fog of bugs.
"looks good" deraadt@

free software project. ok beck deraadt
Ports calling FIPS_mode_set(1): mongodb

gets a second trim.

now removed engines.

of des_old.h routines, acting as wrappers about the OpenSSL UI API.
Nothing should use these functions directly.
Riding the recent libcrypto major bump (in a `des' car).

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@

ok beck deraadt

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.

next few moments, don't rush your update.
Requested by deraadt@

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.

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@

meets their needs, but dumping it in here only penalizes the rest of us.
ok beck deraadt

with the bearded ones...
some API's that nobody should be using will dissapear with this commit.