ENGINE surgery. DH, DSA, RAND, and RSA now use *both* "method" and ENGINE
pointers to manage their hooking with ENGINE. Previously their use of
"method" pointers was replaced by use of ENGINE references. See
crypto/engine/README for details.
Also, remove the ENGINE iterations from evp_test - even when the
cipher/digest code is committed in, this functionality would require a
different set of API calls.
applications to use EVP. Add missing calls to HMAC_cleanup() and
don't assume HMAC_CTX can be copied using memcpy().
Note: this is almost identical to the patch submitted to openssl-dev
by Verdon Walker <VWalker@novell.com> except some redundant
EVP_add_digest_()/EVP_cleanup() calls were removed and some changes
made to avoid compiler warnings.
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.
Previously RAND_get_rand_method was returning a non-const pointer, but it
should be const. As with all other such cases, METHOD pointers are stored and
returned as "const". The only methods one should be able to alter are methods
"local" to the relevant code, in which case a non-const handle to the methods
should already exist.
This change has been forced by the constifying of the ENGINE code (before
which RAND_METHOD was the only method pointer in an ENGINE structure that was
not constant).
and make all files the depend on it include it without prefixing it
with openssl/.
This means that all Makefiles will have $(TOP) as one of the include
directories.
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
but will verify the signatures on a response
and locate the signers certifcate.
Still needs to implement a proper OCSP certificate
verify.
Fix warning in RAND_egd().
only queried when the /dev/[u]random devices did not return enough
entropy. Only the amount of entropy missing to reach the required minimum
is queried, as EGD may be drained.
Queried locations are: /etc/entropy, /var/run/egd-pool
them for a short period of time (actually, poll them with select(),
then read() whatever is there), which is about 10ms (hard-coded value)
each.
Separate Windows and Unixly code, and start on a VMS variant that
currently just returns 0.
doesn't quite work on WinNT 4 earlier than SP6. It works fine on
Windows 98 and Windows 2000.
I'm disabling it for now. What's really needed is some kind of check
to see if GetCursorInfo is safe to call, or alternatively, GetCursor
or GetCursorPos could be used, according to Jeffrey.
- Make sure PCURSORINFO is defined even on systems that do not provide it.
- Change the reference to Peter Gutmann's paper.
- Make sure we don't walk the whole heap lists for performance reasons.
Jeffrey Altman suggests following Peter Gutmann's advice to keep it
to 50 heap entries per heap list.
it wants to stir the pool using ssleay_rand_add. This fix provides the
possibility to call ssleay_rand_add inside a locked state by simply telling
it not to do any locking through a static variable. This isn't the most
elegant way one could do this, but it does retain thread safety during the
stirring process.
This is mostly a work around for the old VC++ problem
that it treats func() as func(void).
Various prototypes had been added to 'compare' function
pointers that triggered this. This could be fixed by removing
the prototype, adding function pointer casts to every call or
changing the passed function to use the expected arguments.
I mostly did the latter.
The mkdef.pl script was modified to remove the typesafe
functions which no longer exist.
Oh and some functions called OPENSSL_freeLibrary() were
changed back to FreeLibrary(), wonder how that happened :-)
Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages. That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.
This change includes all the name changes needed throughout all C files.
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
(they don't really exist before version 7), so that solution was toast.
Instead, let's do it the way it's done on Unix, but then remove older
versions of the file.
That new mechanism *may* fail for some unixly formated file spec,
although I wouldn't worry too much about it.
this is what we now use to read $RANDFILE / $HOME/.rnd.
(Previously, after 'cat'ting lots of stuff into .rnd
only the first MB would be looked at.)
Bugfix for apps/enc.c: Continue if RAND_pseudo_bytes returns 0
(only -1 is an error).
opening the output file with "wb" to truncate it except on VMS
(where the file now keeps its original length because it is opened
with "rb+" -- does VMS have ftruncate?)
returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.
don't try to detect fork()s by looking at getpid().
The reason is that threads sharing the same memory can have different
PIDs; it's inefficient to run RAND_seed each time a different thread
calls RAND_bytes.
between SSLeay 0.8.1b and 0.9.0b with no apparent reason).
If we *want* an error when DEVRANDOM is not defined (it always is with
the current e_os.h) we should use #error.
This will soon be complemented with MacOS specific source code files and
INSTALL.MacOS.
I (Andy) have decided to get rid of a number of #include <sys/types.h>.
I've verified it's ok (both by examining /usr/include/*.h and compiling)
on a number of Unix platforms. Unfortunately I don't have Windows box
to verify this on. I really appreciate if somebody could try to compile
it and contact me a.s.a.p. in case a problem occurs.
Submitted by: Roy Wood <roy@centricsystems.ca>
Reviewed by: Andy Polyakov <appro@fy.chalmers.se>
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
There were problems with putting e_os.h just into the top directory,
because the test programs are compiled within test/ in the "standard"
case in in their original directories in the makefile.one case;
and in the latter symlinks may not be available.
script, translates function codes better and doesn't need the K&R function
prototypes to work (NB. the K&R prototypes can't be wiped just yet: they are
still needed by the DEF generator...). I also ran the script with the -rewrite
option to update all the header and source files.
consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally
cleaned up the `make links' target: Remove unnecessary semicolons, subsequent
redundant removes, inline point.sh into mklink.sh to speed processing and no
longer clutter the display with confusing stuff. Instead only the actually
done links are displayed.
1. The already released version was 0.9.1c and not 0.9.1b
2. The next release should be 0.9.2 and not 0.9.1d, because
first the changes are already too large, second we should avoid any more
0.9.1x confusions and third, the Apache version semantics of
VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
.2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------
