(basically: whooops :-))

flag as discussed on the mailing list.

Purpose and trust setting functions for X509_STORE.

Tidy existing code.

inherited from X509_STORE.

Add CRL checking options to other applications.

Initial CRL based revocation checking.

little bit clearer and use the new OPENSSL_SYS_* macros.

like des_read_password and friends (backward compatibility functions
using this new API are provided).  The purpose is to remove prompting
functions from the DES code section as well as provide for prompting
through dialog boxes in a window system and the like.

For those, unless the environment variables RANDFILE or HOME are
defined (the default case!), RAND_file_name() will return NULL.
This change adds a default HOME for those platforms.

To add a default HOME for any platform, just define DEFAULT_HOME in
the proper place, wrapped in appropriate #ifdef..#endif, in e_os.h.

ENGINE code does not return a default, set an error.

define LLONG properly for VC++.

stop compiler complaining about signed/unsigned mismatch in apps/engine.c

"Howard Chu" <hyc@highlandsun.com>, it may be general enough
to work on any Unixly system.

turned on, and (b) left a somewhat curious debugging string in the output.

few statements equivalent to "ENGINE_add(ENGINE_openssl())" etc. The inner
call to ENGINE_openssl() (as with other functions like it) orphans a
structural reference count. Second, the ENGINE_cleanup() function also
needs to clean up the functional reference counts held internally as the
list of "defaults" (ie. as used when RSA_new() requires an appropriate
ENGINE reference). So ENGINE_clear_defaults() was created and is called
from within ENGINE_cleanup(). Third, some of the existing code was
logically broken in its treatment of reference counts and locking (my
fault), so the necessary bits have been restructured and tidied up.

To test this stuff, compiling with ENGINE_REF_COUNT_DEBUG will cause every
reference count change (both structural and functional) to log a message to
'stderr'. Using with "openssl engine" for example shows this in action
quite well as the 'engine' sub-command cleans up after itself properly.

Also replaced some spaces with tabs.

Tru64 shared libraries can be linked with static libraries.

 * "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
   that allows an ENGINE to store its own information there rather than in
   global variables. It follows the declarations and implementations used
   in RSA code, for better or worse. However there's a problem when storing
   state with ENGINEs because, unlike related structure types in OpenSSL,
   there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
   is, it has method pointers as its structure elements ...  which leads
   to;

 * ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
   reference to an "implementation" (eg. to get to a hardware device), but
   should also be able to maintain state, then this flag can be set by the
   ENGINE implementation. The result is that any call to ENGINE_by_id()
   will not result in the existing ENGINE being returned (with its
   structural reference count incremented) but instead a new copy of the
   ENGINE will be returned that can maintain its own state independantly of
   any other copies returned in the past or future. Eg. key-generation
   might involve a series of ENGINE-specific control commands to set
   algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
   generate the key. An ENGINE doing this would *have* to declare
   ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
   maintained "per-handle" and unaffected by other code having a reference
   to the same ENGINE structure.

takes care of what would otherwise be seen as a memory leak.

unless there's a default clause.

appropriate code if any of them is defined.

here.

We shouldn't skip over header files to avoid functions of disabled algorithms.  The selection is done in a different way

Spotted by Mark Crispin <MRC@Panda.COM>