bignums are passed in and out of functions and APIs in a consistent form
has highlighted that zero-valued bignums don't need any allocated word
data. The use of BN_set_word() to initialise a bignum to zero causes
needless allocation and gives it a return value that must be checked. This
change converts BN_zero() to a self-contained macro that has no
return/expression value and does not cause any expansion of bignum data.

Note, it would be tempting to rewrite the deprecated version as a
success-valued comma expression, such as;
   #define BN_zero(a) ((a)->top = (a)->neg = 0, 1)
However, this evaluates 'a' twice and would confuse initialisation loops
(eg. while(..) { BN_zero(bn++) } ). As such, the deprecated version
continues to use BN_set_word().

change to work properly; BN_zero() should set 'neg' to zero as well as
'top' to match the behaviour of BN_new().

redefine bn_clear_top2max() to be a NOP in the non-debugging case, and
remove some unnecessary usages in bn_nist.c.

Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe, Ulf Möller

return a "zero" bignum as BN_new() does - so reset 'top'. During
BN_CTX_end(), released bignums should be consistent so enforce this in
debug builds. Also, reduce the number of wasted BN_clear_free() calls from
BN_CTX_end() (typically by 75% or so).

Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe, Ulf Möller

when X509_V_FLAG_X509_STRICT is set. Check for CRLSign in
CRL issuer certificates. Reject CRLs with unhandled (any)
critical extensions.

Reported by: Jose Castejon-Amenedo <Jose.Castejon-Amenedo@hp.com>

Notified by Paul Siegel <psiegel@corestreet.com>

PR: 833

Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe

Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe

The old raw format can't be handled by some implementations
and updates to RFC2560 will make this mandatory.

PR: 821

memory allocate when calling EVP_MD_CTX_copy_ex().

Without this HMAC is several times slower than
< 0.9.7.

Add the corresponding AES parts while I'm at it.
make update

_POSIX_C_SOURCE needed in first place.

Windows).

let's check for those macros, and if they aren't defined, let's assume
there aren't Unixly devices on this platform.

automatically to accomodate the value, some compilers fail to do so. Most
notably 0x0123456789ABCDEF should come out as long long in 32-bit context,
but HP compiler truncates it to 32-bit value. Which in turn breaks GF(2^m)
arithmetics in hpux-parisc2-cc build. Therefore this fix...

VMS.  The C RTL can handle it well if the "directory" is a logical
name with no colon, therefore ending being 'logname/file'.  However,
if the given logical names actually has a colon, or if you use a full
VMS-syntax directory, you end up with 'logname:/file' or
'dev:[dir1.dir2]/file', and that isn't handled in any good way.

So, on VMS, we need to check if the directory string ends with a
separator (one of ':', ']' or '>' (< and > can be used instead [ and
])), and handle that by not inserting anything between the directory
spec and the file name.  In all other cases, it's assumed the
directory spec is a logical name, so we need to place a colon between
it and the file.

Notified by Kevin Greaney <kevin.greaney@hp.com>.

Submitted by: Gertjan van Oosten <gertjan@West.NL>

PR: #804

This is part of a large change submitted by Markus Friedl <markus@openbsd.org>

This is part of a large change submitted by Markus Friedl <markus@openbsd.org>

specially if it is.
Add a few OpenBSD-specific cases.
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>