Submitted by: Nils Larsch

create new lock CRYPTO_LOCK_BN to avoid race condition

Submitted by: Nils Larsch

Submitted by: Nils Larsch

build them there.

A command procedure to build the external engines is on it's way.

into libcrypto, we need the "algorithm" STATIC_ENGINE.

first.

of libcrypto, then it is possible that when they are loaded they will share
the same static data as the loading application/library. This means it will
be too late to set memory/ERR/ex_data/[etc] callbacks, but entirely
unnecessary to try. This change puts a static variable in the core ENGINE
code (contained in libcrypto) and a function returning a pointer to it. If
the loaded ENGINE's return value from this function matches the loading
application/library's return value - they share static data. If they don't
match, the loaded ENGINE has its own copy of libcrypto's static data and so
the callbacks need to be set.

Also, although 0.9.7 hasn't been released yet, it's clear this will
introduce a binary incompatibility between dynamic ENGINEs built for 0.9.7
and 0.9.8 (though others probably exist already from EC_*** hooks and
what-not) - so the version control values are correspondingly bumped.

normal 'structural' case (ENGINE_init() satisfies this in the less normal
'functional' case). This change provides such a function.

- Correct some "read" locks that should actually be "write" locks.

- make update.

word, since that word may not be zero.

the same source file.

PR: 253

between calls, or that will be lost if it returned with *num non-zero.

automatic load of dynamic engines.  Change the iterator to try to load
the requested engine dynamically.  The environment variable
OPENSSL_ENGINES can be used to override the internal default directory
where one can expect to find dynamically loadable engines.

Note: The changes in step 11 have all been made by Geoff Thorpe.
Credit where credit is due.

automatic load of dynamic engines.  Add functionality to the dynamic
engine to handle engine directories and loading from those.  This
is currently NOT compatible with the use of LD_LIBRARY_PATH and
similar environment variables.

Note: The changes in step 11 have all been made by Geoff Thorpe.
Credit where credit is due.

automatic load of dynamic engines.  Unless we don't have shared
library support, do not try to load any "built-in" engines except for
cryptodev.

don't build any "built-in" engines in that directory any more, except
fo the cryptodev one.

eng_cryptodev.c.  This is an engine that (at least currently) has
to be built in.

Correct misspelled VXWORKS macros.
Add VXWORKS identifying macros to e_os2.h.
Add required inclusions and mappings for VxWorks in e_os.h.
A few small modifications to make OpenSSL build and work on VxWorks.
PR: 253, except for the  change that was handled in an earlier
         commit, and a request for easy build of just parts of OpenSSL.

give it.
For 0.9.7 and up, that means util/domd needs to remove those double
dashes from the argument list when gcc is used to find the
dependencies.

Resolve signed/unsigned conflicts

Make dso_win32.c compile.

when backward compatibility is desired).

Should this be added to 0.9.6-stable as well?
PR: 275

only the first call would provide the correct result.
PR: 277

Various enhancements to PKCS#12 code, new
medium level API, improved PKCS12_create
and additional functionality in pkcs12
utility.

engine with something they claim is better.  I have nothing to compare to,
and I assume they know what they're talking about.  The interesting part with
this one is that it's loaded by default on OpenBSD systems.
This change was originally introduced in OpenBSD's tracking of OpenSSL.

This correction was originally introduced in OpenBSD's tracking of OpenSSL.