in the middle of the code on Windows, and that disrupts operations in functions
later that use rename()...
PR: 853

curves.

Submitted by: Nils Larsch

included.

functions and macros.

This change has associated tags: LEVITTE_before_const and
LEVITTE_after_const.  Those will be removed when this change has been
properly reviewed.

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: #748
Submitted by: Kirill Kochetkov <kochet@ixbt.com>

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

Use BUF_strlcat() instead of strcat().
Use BIO_snprintf() instead of sprintf().
In some cases, keep better track of buffer lengths.
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>

to apps.c, and give it the hopefully descriptive name parse_yesno().

rationale behind the move is that it's use by several applications.
The rationale behind the name change is that it describes what the
function does a bit better.

to 'openssl req' and 'openssl ca'.

PR: 779
Submitted by: Michael Bell <michael.bell@cms.hu-berlin.de>
Reviewed by: Richard Levitte

(there will be some follow-up changes)

PR: 780
Submitted by: Verdon Walker <VWalker@novell.com>
Reviewed by: Richard Levitte

Max req -x509 use V1 if extensions section absent.

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

PR: #748

Submitted by: Goetz Babin-Ebell <babin-ebell@trustcenter.de>

PR: #766

Submitted by: Nils Larsch

callback structure just before it is needed.

I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.

linux system (namely mine) chokes on our definitions and uses of the "HZ"
symbol in crypto/tmdiff.[ch] and apps/speed.c as a "bad function cast"
(when in fact there is no function casting involved at all). In both cases,
it is easily worked around by not defining a cast into the macro and
jiggling the expressions slightly.

In addition - this highlights some cruft in openssl that needs sorting out.
The tmdiff.h header is exported as part of the openssl API despite the fact
that it is ugly as the driven sludge and not used anywhere in the library,
applications, or utilities. More weird still, almost identical code exists
in apps/speed.c though it looks to be slightly tweaked - so either tmdiff
should be updated and used by speed.c, or it should be dumped because it's
obviously not useful enough.

Rather than removing it for now, I've changed the API for tmdiff to at
least make sense. This involves taking the object type (MS_TM) from the
implementation and using it in the header rather than using "char *" in the
API and casting mercilessly in the code (ugh). If someone doesn't like
"MS_TM" and the "ms_time_***" naming, by all means change it. This should
be a harmless improvement, because the existing API is clearly not very
useful (eg. we reimplement it rather than using it in our own utils).

However, someone still needs to take a hack at consolidating speed.c and
tmdiff.[ch] somehow.

and links with OPENSSL_NO_DEPRECATED defined.

PR: 669

In s_server, print the received Kerberos information.
PR: 693

calling X509_verify_cert() in x509.c the cert should
not be added to the trusted store.

platforms that don't (necessarely) have it.  In the case of VMS, this
means moving a couple of functions from apps/ to crypto/ and make them
general (although only used privately).

exiting on the first error in a request.

invalid cases)

PR: 674

Submitted by: Douglas Stebila
Reviewed by: Bodo Moeller

subject hash, with -hash a synonym kept around for backward
compatibility reasons.
PR: 650

Submitted by: Nils Larsch

Contributed in whole by Laurent Genier <Laurent.Genier@intrinsec.com>
PR: 644