On Thu, Jan 24, 2002 at 02:32:24AM -0500, Jeffrey Altman wrote: > > djm> > The other problem is applications > > djm> > that link either with libdes or with openssl's libcrypto. The latter > > djm> > will very suddenly fail. > > djm> > > djm> How? These apps would need to be recompiled anyway - that way they would > > djm> pick up the macros. > > > > If we retain the old symbols in the library, which is currently > > expected, they don't need to recompile. Re*linking* would be > > sufficient to satisfy the linkers idea of what the program needs.
Hmm. OpenSSL 0.9.7 is not binary/API compatible with the 0.9.6x series. Applications must be recompiled anyway. > > djm> > But, this isn't the end of the story. On some architectures, there > > djm> > are binary incompatibilities between openssl's libcrypto and libdes. > > djm> > > djm> Aren't these what you are trying to avoid in the first place? > > djm> The libdes shipped with MIT krbIV is an ongoing source of frustration for > > djm> the portable OpenSSH developers. > > > > Yes, you're right, that's what we try to avoid. However, we've > > already had complaints about not providing the old symbols by default, > > so guess how people will react if they are missing in the library as > > well. It should not matter, as they need to recompile anyway, so macros to redefine the functions would be picked up. If the des_old functionality cannot be achieved using macros, we can still leave the wrapper functions but rename them: #define des_ecb3_encrypt(input,output,ks1,ks2,ks3) \ DES_old_ecb3_encrypt(input,output,ks1,ks2,ks3) and then call the wrapper functions des_old_*(). In this way the argument handling can be done in real functions, but in the library they are found as "des_old_*", so we will never see a problem of the linker finding the wrong functions. Looks ugly? But it would help to solve the conflict. > We knew there were going to be complaints no matter what was decided. > However, I thought the consensus was that OpenSSL pre-1.0 is not > api compatible between releases. Therefore, it didn't matter that > the function names would change and the libraries would not be > compatible. The longer this change gets put off the more difficult > it will be to fix because there will be an ever increasing number > of applications relying on it. I agree on that this problem must be solved. In former times with export restrictions the amount of cryptographic code and options (kerberos etc) was much smaller. Now that much more code of this type is available the amount of possible conflicts should be minimized. OpenSSL already cleared its namespace by moving include files into openssl/*.h allowing inclusion of similar header files with the same name, now the contents must also be worked out :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]