Hi,
On Thu, 28 Oct 1999, Richard Levitte - VMS Whacker wrote:
> SalzR> Absolutely. For my servers, I know better than openssl how to
> SalzR> manage memory. For example, I want my memory pools per-thread
> SalzR> so that I don't have to make "malloc" be a critical-region.
>
> Like you don't have to today. As soon as you play with BN thingies,
> you're using malloc() all over the place. RSA and friends are stuff
> that use BN...
This is a good point. Apart from the ugliness of having to have all the
internal structures defined in API header files (ie. BN, RSA, X509, SSL,
SSL_CTX, etc etc) ... there is still the memory handling problem that
somebody thought would be *created* by using handles or pointer types
rather than direct access to underlying structures. eg.
void mem_leak() {
BIGNUM blah;
BN_init(&blah);
BN_bin2bn(some_array, array_len, &blah);
}
Even with it in this form (which is not shared-library friendly and will
not behave well if a future OpenSSL expands the BIGNUM type, as was the
original point) it still involves a malloc and it still involves a memory
leak unless the caller explicitly cleans up after him/herself. I'd rather
see the whole thing shift to handle based types where at least the library
itself can keep track of memory usage (even if the caller leaves certain
handles orphaned) and the gory details of the internal structures (which
may obviously change over time) need not be exposed to users and kept
carefully up-to-date with the particular version of the shared-library
they're using.
It would also make it much easier to do a number of things OpenSSL is
crying out for. Off the top of my head, I could think of abstracting
"keys" to support hardware key-management, smart cards, remote key
operations, protection from memory-scanning attacks, database
[key|cert]sets, etc - reference counting the use of handles per
thread/process so that cleaning up after leaky (or crashed)
threads/processes is possible ... all stuff that is hideously difficult
with the current interface because users expect to know and have direct
access to the internals of "objects".
> If there was an easy way to sneak in some constant value into programs
> and have some libcrypto routines check that it matches a value they
> believe in, a different kind of check would be possible, having that
> routine refuse to work, with the optional nice message telling the
> user that the program needs recompiling. That would be better than a
> SEGV or a program that misbehaves because the stack got trashed.
This could also be used to allow future design improvements (eg.
cert-chain checking starts enforcing key-usage constraints) to fold back
to the behaviour expected by older programs, or if that is not possible,
do as you say - notify the caller that the current library is "too
[old|new]" for their program and they need a more appropriate library
version. However, when the library ceases to be API compatible, I'd prefer
to see a version number change in the library file itself (in the manner
of libc perhaps) so that there is less usage confusion (and it becomes
possible to maintain when multiple OpenSSL-based programs require
different versions of OpenSSL shared libraries). Perhaps this is already
the case?
> Then there's COM, but I think that's beyond the scope here...
[;-)
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
