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

PR: 834

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

If -offset exceeds -length of data available exit with an error.

Don't read past end of total data available when -offset supplied.

If -length exceeds total available truncate it.

PR: 821

memory allocate when calling EVP_MD_CTX_copy_ex().

Without this HMAC is several times slower than
< 0.9.7.

non-strict prototypes, all right?  Kind of shadows the few other
warnings so I keep missing them :-)).

functionality.  Therefore, I'm backing out most of the "CFB DES
sync-up with FIPS branch" commit (I'm keeping the corrections of
DES_cfb_encrypt()).

Windows).

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

PR: 772

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>.

PR: #748
Submitted by: Kirill Kochetkov <kochet@ixbt.com>

PR: #570
Submitted by: Martin Witzel <MWITZEL@de.ibm.com>

Submitted by: "Martin Witzel" <MWITZEL@de.ibm.com>

PR: #570

'OpenSSL_0_9_7-stable'.

Submitted by: "Martin Witzel" <MWITZEL@de.ibm.com>

PR: #570

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

PR: #804