OpenSSH and OpenSSL snapshots

[Jeffrey Altman]

> 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.
> 
> 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.
> 
> This mess is our own fault in a way.  We changed the des API from the
> libdes form, and thereby created a number of source-level
> incompatibilities, which leads to clashes when people need to
> interchange libdes and libcrypto in a fairly elegant way.

Richard:

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.

The only way that this can be handled is to use macros to map from
the old api to the new functions.  I do not see any other way that
will allow the libdes.a to be mixed with libcrypto.a.  

- Jeff




 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 available now!!!
 The Kermit Project @ Columbia University   includes Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 kermit-support at columbia.edu                OpenSSL. Interfaces with OpenSSH