1) Building with 'no-rsa' (compiler: -DNO_RSA) causes link errors on
UNIX. I "fixed" the problem, but my fix was pretty brute-force: I just put
"#ifndef"s around the offending calls. I'm certain I introduced runtime
errors, crashes, etc. by circumventing the calls like that without any new
code or code changes to accommodate the "missing" calls, but I wasn't using
that stuff and it builds and runs now. (The point is: The reason I'm not
supplying the fix is because I know my fix is wrong and I did it half-baked
at best).
Specifically, I was building with "no-rsa no-rc4 no-rc5 no-idea no-bf"
2) SSL_CTX_set_tmp_dh hangs. (It didn't with the distribution of 9.5a,
but it does with the new snapshot). Ultimately, SSL_CTX_set_tmp_dh ends up
calling 'ssleay_rand_bytes', which then calls 'ssleay_rand_add'. The problem
appears to be that 'ssleay_rand_bytes' calls
CRYPTO_w_lock(CRYPTO_LOCK_RAND)', and then 'ssleay_rand_add' calls
CRYPTO_w_lock(CRYPTO_LOCK_RAND)' again before it gets unlocked, causing a
deadlock.
The call to CRYPTO_w_lock(CRYPTO_LOCK_RAND) from ssleay_rand_bytes is in
'crypto/rand/md_rand.c' right after the big comment that starts "(Based on
the rand(3) manpage:)", and the call to ssleay_rand_add is in the "if
(do_stir_pool)" block shortly thereafter. ssleay_rand_add calls
RYPTO_w_lock(CRYPTO_LOCK_RAND) as soon as it's entered.
I fixed this (or so I say<G>) by unlocking CRYPTO_LOCK_RAND before calling
ssleay_rand_add. I'm not sure if the data that we are protecting in there
is in a partially-changed state or a safe-rentry state at that time, so I'm
not sure about the quality of the fix. It works for me because I only ever
call the function once, and it doesn't hang now, but it may be thread-unsafe
now. Here's what I did (I just added the two lines with "Brebey" by them)
...in crypto/rand/md_rand.c...
......in "ssleay_rand_bytes (...)"
.........
.........code omitted...
.........
if (do_stir_pool)
{
/* Our output function chains only half of 'md', so
we better
* make sure that the required entropy gets 'evenly
distributed'
* through 'state', our randomness pool. The input
function
* (ssleay_rand_add) chains all of 'md', which makes
it more
* suitable for this purpose.
*/
int n = STATE_SIZE; /* so that the complete pool
gets accessed */
/* BRebey - KLUDGE; Maybe this shouldn't be here! */
CRYPTO_w_unlock(CRYPTO_LOCK_RAND);
while (n > 0)
{
#if MD_DIGEST_LENGTH > 20
# error "Please adjust DUMMY_SEED."
#endif
#define DUMMY_SEED "...................." /* at least
MD_DIGEST_LENGTH */
/* Note that the seed does not matter, it's
just that
* ssleay_rand_add expects to have something
to hash. */
ssleay_rand_add(DUMMY_SEED,
MD_DIGEST_LENGTH, 0.0);
n -= MD_DIGEST_LENGTH;
}
if (ok)
stirred_pool = 1;
/* BRebey - KLUDGE; Maybe this shouldn't be here! */
CRYPTO_w_lock(CRYPTO_LOCK_RAND);
}
.........
.........code omitted...
.........
}
I doubt this is a valid fix, but it worked for me and as far as I
can tell it needs fixed "for Real" rather than my kludge.
3) Richard Levitte has a fix for a thread-safe problem with lh_delete
in ERR_get_state.
4) I'm still tracking down that sporadic crash in lh_retrieve. Any
ideas would be appreciated.
Bill Rebey
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
