Memory leak in SSL_CTX_new ?

2000-11-16 Thread Paul Keogh
I've been doing some memory leak checking on an OpenSSL app and discovered that a memory leak occurs in SSL_CTX_new(). Stack trace is below. The SSL_get_ex_data_X509_STORE_CTX_idx() function is used to check for an error but internally allocates resources which SSL_CTX_free() does not free up.

Re: Plz help ! Can't build OpenSSL 0.9.6 with BCB4.

2000-11-16 Thread Ulf Möller
On Wed, Nov 15, 2000 at 09:00:43PM -0500, Rich Salz wrote: The real fix would be to eliminate all remaining non-ANSI constructs (that have still be left in because of their implicit type conversion). Are there any of those? Functions that take unpromoted types, I mean. Yes, see the

Re: Hmm... (discoveries about BIGNUM code)

2000-11-16 Thread Michael Sierchio
Rich Salz wrote: after I pointed it out), that calling realloc() in the code will leave lots of copies of private keys and other sensitive data lying around in memory. The bignum code should never call the libc realloc(), but should instead use a safe realloc which does a malloc(), a

[Patch] for linux/sparc-v8

2000-11-16 Thread Raoul Borenius
Hi, I just compiled openssl-0.9.6 on my sparc-linux-box (SS 20) and I think there is a small bug in ./config while trying to detect the hardware by reading '/proc/cpuinfo'. On my box there are two lines containing the string 'type' and this leads to a wrong guess by the config-script. Here is

Re: [Patch] for linux/sparc-v8

2000-11-16 Thread Richard Levitte - VMS Whacker
From: Raoul Borenius [EMAIL PROTECTED] borenius I just compiled openssl-0.9.6 on my sparc-linux-box (SS 20) borenius and I think there is a small bug in ./config while trying to borenius detect the hardware by reading '/proc/cpuinfo'. borenius borenius On my box there are two lines containing

Re: OpenSSL problems 11/16/00.

2000-11-16 Thread Lutz Jaenicke
This is a problem for openssl-users... On Thu, Nov 16, 2000 at 12:30:16PM -0500, Castoldi, Gino wrote: I am having trouble building the OpenSSL libraries. I am running the make utility on a HP-UX 11.0 system(S821 series/L2000 server). The output is listed below. ... cc -I.

Re: Hmm... (discoveries about BIGNUM code)

2000-11-16 Thread Geoff Thorpe
Hey there, On Thu, 16 Nov 2000, Richard Levitte - VMS Whacker wrote: I was wrong, it doesn't a realloc(), it does a malloc followed later on by a free(). However, I found no place where the expansion zeroes the previous memory, not even before I made my changes in there. I will take your

Re: Hmm... (discoveries about BIGNUM code)

2000-11-16 Thread Richard Levitte - VMS Whacker
From: Geoff Thorpe [EMAIL PROTECTED] geoff Might I propose another thought? We implement a sanitising heap geoff around malloc/realloc/free and allow it to be substituted in geoff (or even substituted *out* if we want it by default?) by geoff calling a new CRYPTO_set_safe_mem_functions(void)

Re: Hmm... (discoveries about BIGNUM code)

2000-11-16 Thread Richard Levitte - VMS Whacker
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] levitte From: Geoff Thorpe [EMAIL PROTECTED] levitte levitte geoff Might I propose another thought? We implement a sanitising heap levitte geoff around malloc/realloc/free and allow it to be substituted in levitte geoff (or even substituted

Re: nonblocking crypto (was: Re: ASN1 non blocking I/O...)

2000-11-16 Thread Tom Biggs
At 09:21 PM 11/15/00 -0800, Dan wrote: My API proposal was meant to generate discussion. I realize it's not an especially practical direction to move OpenSSL in. Does the idea of an event-driven SSL API appeal to anybody, at least in the abstract? Yes.

RE: RSA encryption. How to use xxx_PADDING.

2000-11-16 Thread Reddie, Steven
Sounds a little confusing. If there's no easy way to tell at decryption time which blocks use which padding type then you've got a problem. If you don't mind potentially having an extra block, perhaps you should use PKCS1_PADDING for all blocks (ie. encrypt the first "key size - 11 bytes", then

Re: Hmm... (discoveries about BIGNUM code)

2000-11-16 Thread robert bonomi
Date: Thu, 16 Nov 2000 19:12:23 +0100 (MET) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Hmm... (discoveries about BIGNUM code) From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] X-Waved: dead chicken, GNU Emacs 20.7.1, Mew version 1.95b43 From: