Hello, In order to experiment with OpenCA, I have built an RPM for redhat 7.2 of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built with the different target directories and libraries. Unfortunately these recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs that I have been able to find. None of them seem to compile successfully, even the snapshots at ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a branch of the CVS tree which I can checkout that will compile with recent OpenSSL builds? Paul-Andre Panon Sierra Systems Group Inc.
On Mon, Jan 21, 2002 at 03:20:55PM -0800, root wrote:> Hello, > > In order to experiment with OpenCA, I have built an RPM for redhat 7.2 > of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built > with the different target directories and libraries. Unfortunately these > recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs > that I have been able to find. None of them seem to compile > successfully, even the snapshots at > ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a > branch of the CVS tree which I can checkout that will compile with > recent OpenSSL builds?what did the OpenSSL people change? what did break?
Here follows the error message I'm getting. I get it with the 3.0.2p1 source
rpm, as well as when I replace the RPM's openssh tarball contents with those
of the latest openssh snapshot. cipher.h is part of the openssh distribution
and itself includes a bunch of openssl include files. I haven't yet tracked
down which openssl include file is the problem, I thought I would first find
out if anyone else is experiencing the same problem or whether it had been
solved in a separate OpenSSH CVS branch.
As for changes in 0.9.7 dev, there's quite a few, not the least of which is
merging of the openssl engine into the core distribution.
make[1]: Leaving directory
`/usr/src/redhat/BUILD/openssh-3.0.2p1/openbsd-compat'
i386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall -Wpointer-arith
-Wno-uninitialized -I. -I. -DETCDIR=\"/etc/ssh\"
-D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/openssh/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/libexec/openssh/sftp-server\"
-D_PATH_SSH_PIDDIR=\"/var/run\"
-DSSH_RAND_HELPER=\"/usr/libexec/openssh/ssh-rand-helper\"
-DHAVE_CONFIG_H
-c atomicio.ci386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall
-Wpointer-arith -Wno-uninitialized -I. -I. -DETCDIR=\"/etc/ssh\"
-D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/openssh/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/libexec/openssh/sftp-server\"
-D_PATH_SSH_PIDDIR=\"/var/run\"
-DSSH_RAND_HELPER=\"/usr/libexec/openssh/ssh-rand-helper\"
-DHAVE_CONFIG_H
-c authfd.c
In file included from authfd.c:50:
cipher.h:68: parse error before `des_key_schedule'
cipher.h:68: warning: no semicolon at end of struct or union
cipher.h:68: warning: no semicolon at end of struct or union
cipher.h:69: warning: no semicolon at end of struct or union
cipher.h:70: warning: type defaults to `int' in declaration of `des'
cipher.h:70: warning: data definition has no type or storage class
cipher.h:72: parse error before `des_key_schedule'
cipher.h:72: warning: no semicolon at end of struct or union
cipher.h:73: warning: type defaults to `int' in declaration of `key2'
cipher.h:73: warning: data definition has no type or storage class
cipher.h:74: parse error before `key3'
cipher.h:74: warning: type defaults to `int' in declaration of `key3'
cipher.h:74: warning: data definition has no type or storage class
cipher.h:75: parse error before `iv1'
cipher.h:75: warning: type defaults to `int' in declaration of `iv1'
cipher.h:75: warning: data definition has no type or storage class
cipher.h:76: parse error before `iv2'
cipher.h:76: warning: type defaults to `int' in declaration of `iv2'
cipher.h:76: warning: data definition has no type or storage class
cipher.h:77: parse error before `iv3'
cipher.h:77: warning: type defaults to `int' in declaration of `iv3'
cipher.h:77: warning: data definition has no type or storage class
cipher.h:78: warning: type defaults to `int' in declaration of `des3'
cipher.h:78: warning: data definition has no type or storage class
cipher.h:93: parse error before `}'
cipher.h:93: warning: type defaults to `int' in declaration of `u'
cipher.h:93: warning: data definition has no type or storage class
cipher.h:95: parse error before `}'
make: *** [authfd.o] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.77886 (%build)
Bad exit status from /var/tmp/rpm-tmp.77886 (%build)
-----Original Message-----
From: Markus Friedl [mailto:markus at openbsd.org]
Sent: Monday, January 21, 2002 3:28 PM
To: root
Cc: openssh-unix-dev at mindrot.org
Subject: Re: OpenSSH and OpenSSL snapshots
On Mon, Jan 21, 2002 at 03:20:55PM -0800, root wrote:> Hello,
>
> In order to experiment with OpenCA, I have built an RPM for redhat 7.2
> of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built
> with the different target directories and libraries. Unfortunately these
> recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs
> that I have been able to find. None of them seem to compile
> successfully, even the snapshots at
> ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a
> branch of the CVS tree which I can checkout that will compile with
> recent OpenSSL builds?
what did the OpenSSL people change? what did break?
On 23 Jan 2002, Damien Miller wrote:> On Wed, 2002-01-23 at 03:27, Booker C. Bense wrote: > > > - The api hasn't changed that much, a simple query-replace > > with /des_/DES_/ should fix the src code tree once and for > > all. > > That won't work - we have to support currently deployed OpenSSL's as > well as the newest versions. >- It will with this include file. #ifdef OPENSSL_OLD_VERSION #define DES_set_key des_set_key #define DES_key_sched des_key_sched #define DES_ncbc_encrypt des_ncbc_encrypt #define DES_ede3_cbc_encrypt des_ede3_cbc_encrypt #define DES_cblock des_cblock #endif - I think people are making this into a bigger problem than it is. Yes it requires that openssl apps do a bit more work, but it isn't that much and it makes some things possible that just weren't before this change. - Booker C. Bense
> 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
> From: Jeffrey Altman <jaltman at columbia.edu> > > jaltman> The only way that this can be handled is to use macros to map from > jaltman> the old api to the new functions. I do not see any other way that > jaltman> will allow the libdes.a to be mixed with libcrypto.a. > > I'm thinking you're right. At the same time, I want to retain C type > security as well as possible. How about this: I could rename all the > old functions to _old_des_* and then have cpp macros that map des_* to > _old_des_*. That would probably resolve all the issues.Look at what we do in in kssl.c for mapping the kerberos functions from krb5_ to kssl_krb5_ in the windows world. That is exactly what you want to do in this case. Rename the real functions in the library. Then in the des.h header if USE_OLD_DES is defined you #define des_foo old_des_foo and expose the prototypes for the old_des_foo function. 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