RE: OpenSSL nasty shared library issue...

[Richard Levitte - VMS Whacker]

From: "Salz, Rich" <[EMAIL PROTECTED]>

SalzR> >No entirely true.  It's very possible to use, if you make sure
SalzR> >you have a standard replacement alloca() for those
SalzR> >architecture that don't have it.
SalzR> 
SalzR> Oh yuck, recurse once and compare addresses to see which way the
SalzR> stack grows.

I didn't say it's beautiful, I just said it's workable (and don't
forget the little note about it being pretty widespred, perhaps with
slightly different names (like __ALLOCA() on VMS with DEC C)).

SalzR> >There are other solutions, then, like keeping memory pools to
SalzR> >make sure we don't get that kind of fragmentation.  That will
SalzR> require some extra work, however...
SalzR> 
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...


SalzR> To restate, I would hate to see "let's make openssl better
SalzR> support binary shared library version mismatch" come at the
SalzR> expense of "trust me, I know you always want malloc()."
SalzR> Especially if "recompile" solves the first part.

True, but where is the solution to "we upgraded libcrypto.so and
libssl.so and now everything is immediately crashing around us"?
Yes, a recompile is the answer, but it's really not a smoothe
mechanism.  Unfortunately there is nothing else either, except to
make the library better suited to work as a shared library.  Otherwise
we might as well stay at the .a (or .lib, or .olb, depending on your
religion) level, which is exactly what I'll do with VMS until the
shared library support is better.


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.

Then there's COM, but I think that's beyond the scope here...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-161 43  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis             -- [EMAIL PROTECTED]

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]