On Fri, Mar 02, 2001 at 02:08:41PM +0100, Richard Levitte - VMS Whacker wrote:
> From: Damien Miller <[EMAIL PROTECTED]>
>
> djm> I am wondering if this is enough to break structure alignment. If
> djm> so, is there any way of making OpenSSL more robust in the face of
> djm> different compiler options?
>
> Hmm, I think I saw some structure members that do not get in place
> when certain NO_* macros are defined. I can do a chek of that...
Yep, that's it alright. It's made worse because multiple binary-
incompatible versions of OpenSSL build shared libraries, and all
of them use the same soname. To keep apps linked dynamically with
0.9.5a from breaking when a system is upgraded to 0.9.6, the soname
has to be changed in the new shared library. Doing so allows for
multiple versions of the library to be installed, because the run-
time linker can load the right version of the library for any given
application.
That wouldn't solve the problem Damien's run into, though, because
the structure sizes change depending on which algorithms are enabled
(which leads to EVP_DigestInit() clearing out unsuspecting variables
on the stack when it expects structures to be bigger than they
actually are, which is sure to happen if the calling application was
built with -DNO_MD2 and the library wasn't).
I understand that removing portions of the various structures used
by OpenSSL when certain algorithms are disabled saves memory, but
would it be worth the memory/performance hit to leave the structures
alone and just disable the code which uses them?
I suppose another option is to just add another padding field which
makes sure the structure has a fixed size no matter what, but that's
a much less attractive option.
Hope this helps,
Nalin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
