Problems with OpenSSH using OpenSSL 0.9.8 - libdl not linking
When upgrading OpenSSL to 0.9.8 (from 0.9.7g) I run into problems compiling OpenSSH. Other things like Stunnel compile OK. When I originally ran into this problem, I though maybe OpenSSH wasn't dealing with some OpenSSL changes so I set the issue aside for a while. Now that OpenSSH 4.2p1 is out, I'm back working on this. But so far I cannot figure why this is happening. I'm doing this compile under several Slackware environments, 9.0 through 10.1, with the gcc/ld/make versions found in those environments. But in all these cases, zlib is upgraded to 1.2.3 already. I tried compiling every combination of OpenSSL versions 0.9.7f, 0.9.7g, and 0.9.8 with OpenSSH versions 3.9p1, 4.0p1, 4.1p1, and 4.2p1. The errors are only occurring when OpenSSL 0.9.8 is used, but the error happens during the build of OpenSSH (this I cannot rule out this being an OpenSSH problem). The final message I get in each failing case is: = gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -static -L. -Lopenbsd-compat -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x5c): In function `dlfcn_load': : undefined reference to `dlopen' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0xc2): In function `dlfcn_load': : undefined reference to `dlclose' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0xee): In function `dlfcn_load': : undefined reference to `dlerror' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x185): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x1b2): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x27d): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x2aa): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/../../../libcrypto.a(dso_dlfcn.o)(.text+0x5ad): In function `dlfcn_unload': : undefined reference to `dlclose' collect2: ld returned 1 exit status make: *** [ssh] Error 1 = The functions dlfcn_load(), dlfcn_bind_var(), dlfcn_bind_func(), and dlfcn_unload() are all in OpenSSL. But clearly they need libdl when being linked during the OpenSSH build. OpenSSH does not explicitly have -ldl in this linking step. Since this step works fine with older OpenSSL versions, I presume that the libdl functions needed go included in libcrypto.a somehow. But they are apparently missing when OpenSSL version 0.9.8 is built. I could hack up a fix to make this work. But I think it is better to figure out what is going wrong to cause this just in 0.9.8, and why it works OK in 0.9.7g and before. But I cannot follow the logic of how OpenSSL's Makefile is working to see how libdl might be affected. The only difference I see between Makefiles for 0.9.8 and 0.9.7g is in the HPUX platform. But my platform is Slackware (9.0 through 10.1) on x86. Here are log files of the full building process as run by a script that ensures each build is always started from a fresh unpacking of each tarball. Other combinations (openssh, openssl, and slackware) are also present in the same directory with the same name pattern. This shows the success with 0.9.7g: http://phil.ipal.org/ssl-ssh/openssl-0.9.7g-in-slackware-10.1.txt.gz http://phil.ipal.org/ssl-ssh/openssh-4.2p1-with-openssl-0.9.7g-in-slackware-10.1.txt.gz This shows the failure with 0.9.8: http://phil.ipal.org/ssl-ssh/openssl-0.9.8-in-slackware-10.1.txt.gz http://phil.ipal.org/ssl-ssh/openssh-4.2p1-with-openssl-0.9.8-in-slackware-10.1.txt.gz My script does build SSL as a 4 level version library instead of 3 level with a letter, since that's the only way I can get multiple versions to co-exist on the same system. I hope that's not the issue. All levels are symlinked. I hope someone has some insight into what is going on and what the PROPER way to fix this is (as opposed to hacks I could do that might not work in future versions of either OpenSSL or OpenSSH). Hopefully it is as simple as some configure parameter or just something wrong with the way I have been building OpenSSL. FYI, all these builds are being done in a chroot environment initialized with the respective Slackware system trees, on a single machine, under Linux kernel 2.6.11.8. -- - | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name
plans for SHA-256, SHA-384, SHA-512 ?
Are there any plans to add SHA-256, SHA-384, and SHA-512 to OpenSSL? I have a program that does recursive file tree digesting with many options that don't exist in other programs. I'm wanting to extend it with options to use these digesting algorithms. It already supports MD4, MD5, RMD160, and SHA1 by linking to libcrypto. It's more for completeness than for any specific need to have those algorithms (it's not likely to need crypto strength digesting). -- - | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | - __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.7a and versioning issues
On Thu, Feb 20, 2003 at 12:23:40PM +0100, Richard Levitte - VMS Whacker wrote: | phil-openssl-users What I had to do to get around the problem was to | phil-openssl-users build critical programs like OpenSSH statically so | phil-openssl-users they had no dependency on the shared library. | | That doesn't matter. OpenSSH detects a difference in the shared | library, down to the patch level, so whenever you upgrade OpenSSL, | even within the same series, OpenSSH will stop working. That's | their choice, and I can understand it. If you understand it, could you explain that understanding? Is it because of the API changes? I guess I need to continue to build OpenSSH statically. And if their choice persist even after OpenSSL 1.0.0, that may have to be forever. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.7a and versioning issues
On Thu, Feb 20, 2003 at 06:17:02PM -0500, Jeffrey Altman wrote: | OpenSSH and C-Kermit both perform checks of the version string of the | library versus the version string of the headers the program was | compiled with. This is done to ensure that the OpenSSL header constants | and APIs used to build the program match those in the library. | | Both products must be either statically linked to OpenSSL or be rebuilt | when OpenSSL changes. Is this only during the OpenSSL beta version? Or will it be the case even after OpenSSL stablizes and is released as 1.0.0? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl-0.9.6h.BOGUS* ?
On Mon, Dec 09, 2002 at 02:43:04AM +0100, Richard Levitte - VMS Whacker wrote: | In message [EMAIL PROTECTED] on Mon, 9 Dec 2002 12:29:45 |+1100, [EMAIL PROTECTED] said: | | mlh What's the story behind the openssl-0.9.6h.BOGUS* | mlh files on the ftp site? | | They have an incorrect version number in crypto/opensslv.h. I | retained them for hysterical raisin... historical reason... | | I sent an correction announcement a few hours ago, which mentions the | patch file openssl-0.9.6h.BOGUS-0.9.6h.patch. That name should give | you a bit of a hint :-). It certain gave me a hint, but perhaps not exactly what you expected. I received the correction announcement, but no prior annoucement. And I misread the correction announcement and interpreted it to mean that 0.9.6h was correcting 0.9.6g for the version number alone. It was only after seeing the *BUGUS* files on the rsync site that I reread things and discovered my error. Apparently some announcements are not making it through. OTOH, email is an imperfect medium despite what some people say. My suggestion is to word announcements, even something like this, in a way that does not assume any previous message has been received. Technically everything was right in the announcement, and the error was my own. But better wording could have prevented it, I feel. I'm also wondering if this should not really have resulted in yet a new version, 0.9.6i, to be released in its place. The reason I say that is because there will probably be numerous cases of bogus 0.9.6h copies floating around for quite a while and getting mixed and confused with the correct 0.9.6h because of the lack of any external identification (if someone picked up the 6 Dec copy and didn't get the correction, it will have the same external identity as the correct 8 Dec copy). Given the propensity for things like OpenSSH to be very version sensitive (refuses to link at run time with a version of OpenSSL different than it was built with), this confused labeling of 0.9.6h could result in things like copies of OpenSSH that will run only with the bogus 0.9.6h. I won't feel comfortable about being sure people really are running the same version until 0.9.6i comes out. Surely this would not have been done if the reason for this was a security bug (even if it got detected within a few minutes of release). Now I wonder if the version mismatches could cause a less diligent system administrator to accidentally expose their systems. The fact that OpenSSL uses letter additions to versions which are NOT reflected in the actual .so file produced further complicates the issue. That's a practice I wish would stop (e.g. either stop using the letters, or include the letters in the .so files so I can still use programs that are sensitive to the exact version during a transition). To avoid those problems I have been building OpenSSH statically. So far, Apache/modssl, Curl, Lynx and Stunnel have not complained, so I continue to build those dynamically. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
version numbering
Is 0.9.7 going to continue the version numbering mess that 0.9.6 has? Or can someone please explain how to install 2 or more different versions of openssl that differ by the letter only (such as 0.9.6e and 0.9.6g) so that both versions are present on the system and that programs which were linked to one or the other specifically, such as openssh, can successfully find the correct library and run? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
library dependencies problems
Can someone explain why OpenSSL is compiled in such a way that it can only work with a single version of libc? Other programs and libraries can generally work across a range of versions within the same major version (e.g. for example glibc 2). How do YOU go about upgrading glibc on a machine you access via SSH, for example? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
How to generate CSR without prompts?
I want to generate a CSR without prompts. The reason is so that the CSR can be generated from a web based script form. I could pipe in answers to the prompts, but based on past experience doing things like this, this is not the proper solution since in the future, the order of prompts or what is prompted for might change. The data could be provided in a file, in environment variables, on a command line, or piped in with some kind of identifier paired with each item. Can someone direct me to a document that explains this? The man pages for various openssl commands don't explain this part at all. The web site has even less that what comes with the openssl-0.9.6e distribution. Or do I just need to tear apart the openssl req command source, find what library calls it does, and just call the library myself, and thus re-invent the wheel? Has anyone already done this? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Upgrading issues [0.9.6b to 0.9.6c and more]
In Makefile.ssl I find the following:
@if [ -n $(SHARED_LIBS) ]; then \
tmp=$(SHARED_LIBS); \
for i in $${tmp:-x}; \
do \
if [ -f $$i ]; then \
( echo installing $$i; \
cp -f $$i $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i ); \
fi \
done; \
( here=`pwd`; \
cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
make -f $$here/Makefile link-shared ); \
fi
Because the difference between 0.9.6b and 0.9.6c is NOT reflected
in the library versions, doing an upgrade from 0.9.6b to 0.9.6c
results in the library file being directly written into. This in
turn causes programs that had that library mapped to fail. And
sshd does so rather quickly.
Normally this would not be an issue because normally, the version
of the library source becomes the version of the library installed.
In such cases, writing the upgraded library writes a whole new file
and changing the symlinks does not impact currently mapped copies.
Recompiling and forcibly reinstalling the very same version of most
libraries could certainly be a problem.
In the case of OpenSSL, it is a problem regardless.
One fix is to name the library exactly the same as the source.
That would result in files:
libcrypto.so.0.9.6b (the old one)
libcrypto.so.0.9.6c (newly created)
and symlinks would then be:
libcrypto.so.0.9.6 - libcrypto.so.0.9.6c
libcrypto.so.0 - libcrypto.so.0.9.6
libcrypto.so - libcrypto.so.0
With this method, the old version is not destroyed. One can change
the symlink back to the old version in case of problems that might
occur in the future.
Another way to make sure the library installation does not clobber
existing processes is:
@if [ -n $(SHARED_LIBS) ]; then \
tmp=$(SHARED_LIBS); \
for i in $${tmp:-x}; \
do \
if [ -f $$i ]; then \
( echo installing $$i; \
cp -f $$i $(INSTALL_PREFIX)$(INSTALLTOP)/lib/tmp-$$i; \
chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/tmp-$$i; \
ln -f $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/old-$$i; \
mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/lib/tmp-$$i \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i ); \
fi \
done; \
( here=`pwd`; \
cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
make -f $$here/Makefile link-shared ); \
fi
This ensures not only saving the old library, but also makes the
file switch atomic so that any active process trying to access the
library file directly never sees a time window of none existing,
and gets either the old one or the new one. This then allows cleanly
restarting processes that use the new library files. In the case of
SSH using shared libraries, it also keeps you from being locked out
of remote machines (even if you had multiple instances of sshd on
different ports, they all die with the current method).
--
-
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
-
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
incomplete configuration for shared libs for sparc and s390
While diagnosing why the compilation of openssl-0.9.6c blew up on a linux-sparcv8 platform, I found that in the Configure script, some linux platforms simply don't have any table data for shared libraries at all. I'm curious why. Is it that no one has simply ever completed a porting or testing of shared libraries on these various Linux platforms? Is this something I can supply patches for to developers? Or is this data compiled into this form (in the %table array in Configure) from somewhere else? I'm also curious why the RC4_CHAR setting for sparc. Is that due to alignment limitations? The Configure %table data (formatted by make TABLE) shows for the linux-sparcv8 platform: *** linux-sparcv8 $cc = gcc $cflags = -mv8 -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DBN_DIV2W $unistd = $thread_cflag = -D_REENTRANT $lflags = $bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR $bn_obj = asm/sparcv8.o $des_obj = $bf_obj = $md5_obj = $sha1_obj = $cast_obj = $rc4_obj = $rmd160_obj = $rc5_obj = $dso_scheme = $shared_target= $shared_cflag = $shared_extension = $ranlib = For comparison, here is linux-elf: *** linux-elf $cc = gcc $cflags = -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall $unistd = $thread_cflag = -D_REENTRANT $lflags = -ldl $bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT $bn_obj = asm/bn86-elf.o asm/co86-elf.o $des_obj = asm/dx86-elf.o asm/yx86-elf.o $bf_obj = asm/bx86-elf.o $md5_obj = asm/mx86-elf.o $sha1_obj = asm/sx86-elf.o $cast_obj = asm/cx86-elf.o $rc4_obj = asm/rx86-elf.o $rmd160_obj = asm/rm86-elf.o $rc5_obj = asm/r586-elf.o $dso_scheme = dlfcn $shared_target= linux-shared $shared_cflag = -fPIC $shared_extension = .so.$(SHLIB_MAJOR).$(SHLIB_MINOR) $ranlib = -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: getting shared dynamic libraries
Gerd Schering wrote: On Mon, 17 Jul 2000, you wrote: How can I get shared dynamic libraries (e.g. .so files) of libssl and libcrypto? I've tried "./Configure linux-elf" and that does not give me any more than the 2 .a files. do a "make linux-shared". This builds the libs in the source tree. You have to copy them manually to one of your lib dirs, then run ldconfig or whatever is appropriate for your system. When I do this, subsequently doing "make install" causes all the code to be compiled again, w/o -fPIC. I can't see any make target to do an install differently (there's install and install_docs). I'm wanting to compile SSH, preferrably with shared libraries linked in, as well as code and compile some programs of my own using either libssl or libcrypto, and I definitely want the dynamic shared linkage for this. -- | Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org | phil (at) ipal.net + | Dallas - Texas - USA | [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
getting interim digest
I want to get an interim digest of a data stream. Is the appropriate way to do this to just copy the CTX structure, and call the Final function on that copy? In a library I wrote a while back, I did this by having the function that gets the digest not be destructive, there being a separate destruct call. -- | Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org | phil (at) ipal.net + | Dallas - Texas - USA | [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
