around them.
NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series. However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called). So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem. Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.
OpenSSL-fips-0_9_7-stable.
Since the 0.9.7-stable branch is supposed to be in freeze and should
only contain bug corrections, this change removes the FIPS changes
from that branch.
pushed item. The index is the number of items - 1. And if a NULL item was
found, actually use it.
Finally, provide a little bit of safety in CRYPTO_lock() by asserting the a
requested dynamic lock really must exist, instead of just being silent about it
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.
Submitted by:
Reviewed by:
PR:
In err.c, flags int_error_hash_set and int_thread_hash_set
appear superfluous since we can just as well initialize
int_error_hash and int_thread_hash to NULL.
Change some of the err.c formatting to conform with the rest of
OpenSSL.
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
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.
Also, make sure empty slots of the dynamic lock stack are used.
Actually, I'm not really sure this is the right thing to do, and may
remove it, with an endlessly growing stack as result...
insecure, so a static lock is added to isolate the sensitive parts.
Also, to avoid one thread freeing a lock that is used by another, a
reference counter is added.
be needed in some ENGINE code, and might serve elsewhere as well.
Note that it's implemented in such a way that the locking itself is
done through the same CRYPTO_lock function as the static locks.
WARNING: This is currently experimental and untested code (it will get
tested soon, though :-)).
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.
variety of platforms. A few are missing, and they will be added in
eventually, but as this is new stuff, it was better to not break lots of
platforms in one go that we can't easily test. The changes to "Configure"
should illustrate how to add support to other systems if you feel like
having a go.
NB: I'll add something shortly to allow you to add "dlfcn.h" support on
those platforms that don't have (or need) a dlfcn.h header file. (The
symbol for Configure will probably by "dlfcn_no_h").
Thanks to Richard Levitte, who is responsible for the dso_dl.c support,
understanding the trickier aspects of the build process, and giving great
feedback on everything else.
[Don't use this stuff if you're easily offended by changes to the
interface or behaviour - it's still work in progress.]
PR:
1. Added code to the memory leak detecting code to give the user the
possibility to add information, thereby forming a traceback.
2. Make the memory leak detecting code multithread-safe.
The idea is that we're actually dealing with two separate critical
sections, one containing the hash tables with the information, the
other containing the current memory checking mode. Those should not
be handled with the same lock, especially since their handling overlap.
Hence, the added second lock.
thread-safe (where thread-safe counterparts are not available on all
platforms), and don't memcpy to NULL-pointers
Submitted by: Anonymous
Reviewed by: Bodo Moeller
Also, clean up htons vs. ntohs confusions.
