Hey there,
On Sun, 25 Mar 2001, Larry Rosenman wrote:
> * Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> [010325 14:41]:
> > From: Larry Rosenman <[EMAIL PROTECTED]>
> >
> > ler> * Justin Clift <[EMAIL PROTECTED]> [010325 07:34]:
> > ler> > Hi Peter,
> > ler> >
> > ler> > Can't this be at least worked around by ./configure detecting there will
> > ler> > be a conflict (i.e. being compiled with OpenSSL support on Solaris or
> > ler> > Unixware) then creating something like #define
> > ler> > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having
> > ler> > crypt.c (etc) check for this and not #include <crypt.h> ?
> > ler> >
> > ler> > Things compile fine without <crypt.h> being included, in the case of
> > ler> > OpenSSL support being needed. As the problem appears to be in
> > ler> > already-released versions of OpenSSL, wouldn't the best approach be to
> > ler> > notify the OpenSSL guys (they're decent people, and CC'ing this now to
> > ler> > their developer list) and also work around the problem ourselves?
> > ler> I've been in contact with an OpenSSL guy, and given him a shell
> > ler> account here. He's looking into it.
> >
> > The problem is how to make it smoothe. I'm open for suggestions. And
> > it's not as simple as just skipping compilation of des_encrypt() in
> > OpenSSL, because it's needed internally. I've no idea if the bast way
> > is really to rename the function or something else. Just removing it
> > from the exported headers is *not* the solution, because there will
> > still be a name clash, the only difference being that ld won't make a
> > fuss about it, and the OpenSSL implementation will most probably win,
> > making those who call it thinking it's the libc ds_encrypt() loosers!
> I suspect renaming it would be the best way, since we have 2 major
> (SUN, SCO) vendors claiming a des_encrypt() function in their libcrypt
> and/or libc.
RC4 functions (according to rc4.h) are of the form RC4_***().
SHA functions (according to sha.h) are of the form SHA_***().
MD5 functions (according to md5.h) are of the form MD5_***().
do I need to go on? Unfortunately yes ...
IDEA functions (according to idea.h) are of the form idea_***().
DES functions (according to des.h) are of the form des_***().
etc.
hmm ...
In fact, a quick glance shows that the capitalists are (in alphabetical order);
BF (blowfish), CAST, DH, DSA, MD2, MD4, MD5, MDC2, RC2, RC4, RC5, RSA, SHA,
And the minimalists are;
DES, IDEA
Unaccounted for;
AES/Rijndael, and anything I missed.
perhaps some consistency is in order, with optional backward compatibility
macros there for the legacy/lethargic? I assume this would make the
des_encrypt() problem go away?
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
