OpenSSH and OpenSSL snapshots

[Lutz Jaenicke]

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                             Lutz.Jaenicke at aet.TU-Cottbus.DE
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus