Age | Commit message (Collapse) | Author |
|
declaration :-).
|
|
ENGINE_CTRL_FUNC_PTR.
|
|
|
|
|
|
|
|
|
|
|
|
applications if they were passing a bogus 'flags' parameter yet having
things work as they wanted anyway.
|
|
be cast later on.
|
|
|
|
PR: 287
|
|
the OPENSSL_USE_GMP symbol is defined). Also, I've re-ordered the listing
of other builtin ENGINEs to be alphabetical (though "dynamic" will still
come first).
|
|
PR: 470
|
|
PR: 462
|
|
Submitted by: Thierry Lelegard <thierry.lelegard@canal-plus.fr>
PR: 461
|
|
|
|
warnings.
Reported by: Bernhard Simon.
|
|
|
|
rule for SHA stuff.
PR: 381
|
|
|
|
|
|
Make sure to include openssl/opensslconf.h to make sure we get the
definition of those macros.
|
|
Submitted by: Sheueling Chang <Sheueling.Chang@Sun.COM>
|
|
into libcrypto, we need the "algorithm" STATIC_ENGINE.
|
|
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.
|
|
the same source file.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Should this be added to 0.9.6-stable as well?
PR: 275
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Submitted by: Douglas Stebila
|
|
Additional changes:
- use EC_GROUP_get_degree() in apps/req.c
- add ECDSA and ECDH to apps/speed.c
- adds support for EC curves over binary fields to ECDSA
- new function EC_KEY_up_ref() in crypto/ec/ec_key.c
- reorganize crypto/ecdsa/ecdsatest.c
- add engine support for ECDH
- fix a few bugs in ECDSA engine support
Submitted by: Douglas Stebila <douglas.stebila@sun.com>
|
|
|
|
Changes marked "(CHATS)" were sponsored by the Defense Advanced
Research Projects Agency (DARPA) and Air Force Research Laboratory,
Air Force Materiel Command, USAF, under agreement number
F30602-01-2-0537.
|
|
|