Description of problem: ssl.h includes kssl.h which has the line #include <krb5.h>, but krb5.h is in /usr/kerberos/include. Version-Release number of selected component (if applicable): openssl-devel-0.9.7-3 krb5-devel-1.2.7-5 How reproducible: 100% Steps to Reproduce: 1. compile source that contains "#include <openssl/ssl.h>" 2. 3. Actual results: Stream of errors related to not finding krb5.h Expected results: compilation success Additional info: adding -I/usr/kerberos/include or -DOPENSSL_NO_KRB5 allows the program to compiler, but that's new behavior and I didn't notice anything about it in ssl(3).
This isn't really a bug -- it's an additional requirement if you build OpenSSL with Kerberos support, as we do for 0.9.7. In part because this isn't something you can just guess, I'd recommend using pkg-config to find out where OpenSSL is installed, as it "knows" about OpenSSL 0.9.7 (and later): pkg-config --cflags-only-I openssl pkg-config --cflags openssl If you're maintaining a package, using pkg-config also has other advantages (such as autoconf macros that don't have be copied around from place to place), but until its use becomes more widespread, this workaround will probably be necessary in many places. Defining OPENSSL_NO_KRB5 isn't a viable option, as the library wasn't compiled with it, and if applications and the library disagree as to the sizes of structures (which the application expects to be smaller due to having less members), applications can crash unexpectedly. Marking WONTFIX because this sort of thing has to be fixed in upstream versions of packages in order for OpenSSL's Kerberos support to ever be useful platforms other than Red Hat Linux.
While I agree with Nalin's explanations, I must say it is basically just a big pain ITA trying to build or rebuild OpenSSL-aware packages. I will have to check how RedHat does it. ;-) (E.g. w3m doesn't even use auto*-tools, unless I get around to porting them to it.) Both automatic pull-ins (like "rpm - -rebuild" and manual ("./configure && make && make install") fail miserably, and take some fiddling to get "-I/usr/kerberos/include" into the CFLAGS. So perhaps we should raise the issue with kerberos? I know that kerberos-aware programs do search in /usr/kerberos, but now openssl-aware programs (even "old" legacy ones like pavuk) need to become kerberos-aware. In other words, using openssl (with its fairly "standard" include paths /usr/include or /usr/include/openssl) suddenly requires you to search non-standard include paths, which will fail miserably. How about a "krb5-devel-compat" package with soft links in /usr/include? I could put a smily here, but I'm honest. ;-) But I don't know about kerberos philosophy, so I'd rather politely ask than demand. :) Thanks for listening, Moritz
*** Bug 84331 has been marked as a duplicate of this bug. ***
*** Bug 86471 has been marked as a duplicate of this bug. ***
What a pain.. this will bite most users who try to compile OpenSSL enabled applications on RedHat. pkg-config is a nice initiative. Only problem is that it is not exacly widespread, so not many packages is using it. Also, the integration with autoconf is not good if a package is meant to be portable to platforms where pkg-config is not used. Need to tinker a bit on this one to determine what we should do in the Squid project..
I just ran into this problem trying to build nessus 1.2.7 from both source rpm and tar distributions. I'm amazed the problem is closed wontfix, since it seems to break every opesnssl-aware product that didn't have to worry about kerberos in the past. Come on folks, have you ever heard of backward compatibility? Sure kerberos is a good thing, but you're losing customers if you break products that don't use it. Is there a fix to this I missed? Is moving the kerberos include files an option? Give me something so I don't have to manually modify product code or /usr/include files, and then have to teach my customers how to do it.
Yep, I just got bitten by this one today. I'm still curious why it's got to be in /usr/kerberos anyway; a move of headers to be in /usr/include/kerberos and a minor patch in the openssl package (s/<krb5.h>/<kerberos/krb5.h>/ ssl.h) would seem to be a dynamite fix, and would make this thing go away almost overnight once the relatively small fallout from the fixing of the header location was over. As it is, though, it seems to only be present in RH9, as older and other distros don't see this anomalous-not-buggy behaviour. Considering the really bad but front-running alternative go-to development distros, the lack of this fix could eventually mean bad things for many people. Moo.
Using OpenSSL (particularly 0.9.7) by naively linking against "-lssl -lcrypto" has never worked portably. On some platforms you may need to add -ldl, on others -lm, etc. So, if you don't support picking up OpenSSL via pkg-config, your package will not build correctly on some set of platforms. This set happens to include Red Hat Linux 9, but clearly this lack-of-support in your package is not really a bug in Red Hat Linux.
Some suggestions on how to modify autoconf enabled SSL applications to use pkg-config allowing them to be built on RedHat-9 would permanently close this discussion I think. Squid-cache.org has not yet found a good way to do this. Instead we hardcoded our own detection of RedHat-9 for the time being until a better and clean solution is found.
Assuming you already have checks for ssl.h and -lssl which produce variables such as SSL_CFLAGS and SSL_LIBS for use in makefiles, you could rearrange those checks from if test -r /usr/include/openssl/ssl.h ; then SSL_CFLAGS=-I/usr/include SSL_LIBS="-L/usr/lib -lssl -lcrypto" elif test -r /usr/local/include/openssl/ssl.h ; then SSL_CFLAGS=-I/usr/local/include SSL_LIBS="-L/usr/local/lib -lssl -lcrypto" elif test -r /usr/local/openssl/include/openssl/ssl.h ; then SSL_CFLAGS=-I/usr/local/openssl/include SSL_LIBS="-L/usr/local/openssl/lib -lssl -lcrypto" ... to check if pkg-config is both installed and "knows" about OpenSSL by doing this: if pkg-config --exists openssl 2> /dev/null ; then PKG_CHECK_MODULES(SSL,openssl) else <previous test code> fi The PKG_CHECK_MODULES macro sets SSL_CFLAGS and SSL_LIBS to the right values for the "openssl" package. Here "openssl" could be replaced with "openssl >= 0.9.7" or even a list of packages ("openssl xft" if you want a bad example), and "SSL" could be replaced by an arbitrary prefix for use in constructing the names of the variables.
Here is the config fragment I use in ZMailer suite. If PKGCONFIG is available, and knows about openssl, then it is used. AC_PATH_PROG(PKGCONFIG, pkg-config)dnl AC_SUBST(OPENSSLPREFIX) AC_SUBST(OPENSSLINCL) AC_SUBST(OPENSSLLIB) AC_ARG_WITH(openssl-prefix, [ --with-openssl-prefix=/dir/path (defines both include and lib)], OPENSSLPREFIX="$withval") AC_ARG_WITH(openssl-include, [ --with-openssl-include=/dir/incl/path], OPENSSLINCL="-I$withval") AC_ARG_WITH(openssl-lib, [ --with-openssl-lib=/dir/lib/path], [if test -f "$withval/libssl.so" ; then OPENSSLLIB="$withval/libssl.so $withval/libcrypto.so" else OPENSSLLIB="$withval/libssl.a $withval/libcrypto.a" fi # if test "$withval" != "/usr" -a "$withval" != "/usr/lib"; then # # Operating system dependent runtime path definition :-/ # OPENSSLLIB="-R$withval $OPENSSLLIB" # fi ]) if test -n "$OPENSSLPREFIX" -a -z "$OPENSSLINCL" ; then if test -f "$OPENSSLPREFIX/include/openssl/ssl.h" ; then OPENSSLINCL="-I$OPENSSLPREFIX/include/" else AC_MSG_RESULT([!!! You defined --with-openssl-prefix=$OPENSSLPREFIX, BUT]) AC_MSG_RESULT([!!! there does not exist file $OPENSSLPREFIX/include/openssl/ssl.h !]) fi fi if test -n "$OPENSSLPREFIX" -a -z "$OPENSSLLIB" ; then if test -n "$OPENSSLPREFIX" -a -f "$OPENSSLPREFIX/lib/libssl.so" ; then OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.so $OPENSSLPREFIX/lib/libcrypto.so" # if test "$withval" != "/usr" -a "$withval" != "/usr/lib"; then # # Operating system dependent runtime path definition :-/ # OPENSSLLIB="-R$withval $OPENSSLLIB" # fi elif test -n "$OPENSSLPREFIX" -a -f "$OPENSSLPREFIX/lib/libssl.a" ; then OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.a $OPENSSLPREFIX/lib/libcrypto.a" else AC_MSG_RESULT([!!! You defined --with-openssl-prefix=$OPENSSLPREFIX, BUT]) AC_MSG_RESULT([!!! there does not exist file $OPENSSLPREFIX/lib/libssl.a !]) fi fi if test -n "$OPENSSLINCL" -a -n "$OPENSSLLIB" ; then AC_DEFINE(HAVE_OPENSSL,1,[System has OpenSSL of some version, and want to use it.]) fi AC_ARG_WITH(openssl, [ --with-openssl Search for, and use OpenSSL, if it can be found], [ if test -z "$OPENSSLINCL" ; then # No Explicite setup, lets do some auto-tests if test -n "$PKGCONFIG" ; then # RedHat 8.0 with OpenSSL 0.9.7! OPENSSLINCL="`$PKGCONFIG --cflags-only-I openssl`" OPENSSLLIB="`$PKGCONFIG --libs openssl`" fi if test -n "$OPENSSLINCL" -o -n "$OPENSSLLIB" ; then WHEREOPENSSL="version unknown via pkg-config data" fi fi if test -z "$OPENSSLINCL" ; then # No Explicite setup, lets do some more auto-tests if test -f /usr/local/ssl/include/openssl/ssl.h ; then # Gee, OpenSSL 0.9.3a at default prefix! OPENSSLPREFIX="/usr/local/ssl" OPENSSLINCL="-I$OPENSSLPREFIX/include" if test -f "$OPENSSLPREFIX/lib/libssl.so" ; then OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.so $OPENSSLPREFIX/lib/libcrypto.so" else OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.a $OPENSSLPREFIX/lib/libcrypto.a" fi WHEREOPENSSL="version 0.9.3a (or newer) at default location" fi if test -f /usr/include/openssl/ssl.h ; then # Gee, OpenSSL 0.9.3a at "--prefix=/usr" !!! OPENSSLPREFIX="/usr" OPENSSLINCL="" if test -f "$OPENSSLPREFIX/lib/libssl.so" ; then OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.so $OPENSSLPREFIX/lib/libcrypto.so" else OPENSSLLIB="$OPENSSLPREFIX/lib/libssl.a $OPENSSLPREFIX/lib/libcrypto.a" fi WHEREOPENSSL="version 0.9.3a (or newer) at system root" fi fi if test -n "$OPENSSLINCL" -o -n "$OPENSSLLIB" ; then AC_MSG_RESULT([Found OpenSSL $WHEREOPENSSL]) AC_MSG_RESULT([ OPENSSLINCL=${OPENSSLINCL}]) AC_MSG_RESULT([ OPENSSLLIB =${OPENSSLLIB}]) AC_DEFINE(HAVE_OPENSSL,1,[System has OpenSSL of some version, and want to use it.]) fi ])
A pkg-config solution neatly pushes what appears to be an OS packaging issue (at least, a system library packaging issue) down to the application developers whether or not they care at all about kerberos. I'm amazed that Red Hat's thinks their clients are willing to just accept this. It's bad enough for product developers, but If I were a fortune 500 corporation developing internal applications that got broken in this way after I upgraded the OS, and it happened multiple times, I'd be looking for a different OS. Oh, and by the way, I doubt I'd be using pkg-config for my internal applications. If Red Hat doesn't picture themselves in such a mission critical role, or believes they can play in that market without worrying about backwards compatibility, I have to wonder about their long term prospects as a company. Or, is this a *Linux* issue and not just Red Hat? I don't think Mandrake 9.1 suffers from this problem; maybe they chose not to implement the change to maintain backwards compatibility, or packaged it in such a way as to be transparent to non-kerberos applications. What about SuSE, etc.? I feel like I'm missing something obvious that pushes this into the "don't care" category, but nobody's made it clear if so. I just hear repetitive statements that somehow the application developers are at fault because they don't make optimal use of pkg-config, never mind that things used to work fine without it. I come from an environment where backwards compatability used to be of paramount concern, at least not something you just threw away on a whim by implementing changes without warning that broke applications. Maybe I blinked and things changed since the time I was last supporting a mission critical system.
I won't hazard a guess as to the particular options used to build OpenSSL by other distribution vendors, or why, but I'm going to try to summarize the state of this in Red Hat Linux. Support for the Kerberos key exchange and ciphersuites in TLS is a good thing -- if you have a Kerberos infrastructure, this functionality saves you the trouble of deploying a seperate certificate-based infrastructure which must be maintained alongside the existing one, and if you don't, you can continue to use certificates as before. Implementing this support adds a dependency in OpenSSL for Kerberos headers and libraries. This is not the first time an additional feature in OpenSSL has required additional headers and libraries. Enabling support for zlib compression added dependencies on zlib headers and libraries. Switching to the ENGINE version of 0.9.6, which added dynamically-loadable hardware support, also added dependencies on libdl headers and libraries. This usually seemed to work before because the additional headers were in /usr/include and the OpenSSL shared libraries were linked against their dependent libraries. Having the headers in /usr/include allowed the compiler to find them without needing additional compile-time flags, and having libssl linked against its dependent libraries allowed the run-time linker to satisfy all of the unresolved symbols by loading the libraries which libssl.so had recorded dependencies for, even if the application which linked against libssl didn't have them as well. I say "usually" because it didn't always Just Work. If an application attempted to link statically with libssl and libcrypto, it would have failed because static libraries can't have this sort of dependency information in them -- the linking step would fail due to unresolved symbols. In versions prior to 0.9.7, OpenSSL didn't include pkg-config data, so a developer who was using OpenSSL had to special-case tests for these specific requirements, and had to continue to do so as new versions of OpenSSL were released, sometimes even on a per-OS (or for Linux, a per-distribution) basis. Using pkg-config is a future-proof way to solve this problem. If OpenSSL picks up new dependencies, the pkg-config data file gets updated to reflect it, and developers who are using OpenSSL for applications don't need to do anything to keep things working. That's why it is my preferred solution here.
*** Bug 91865 has been marked as a duplicate of this bug. ***
*** Bug 98224 has been marked as a duplicate of this bug. ***
If pkg-config is needed to build with openssl, I suggest that the openssl-devel package gets a Requires: pkgconfig
*** Bug 99313 has been marked as a duplicate of this bug. ***
Squid-2.5.STABLE6 and later will look for and use pkg-config if available for figuring out the OpenSSL libraries and paths. It is a pity that pkg-config is not UNIX standard in my opinion. If it was then package maintenance would be a lot simpler for packages making use of other packages such as Squid using OpenSSL.
Yeah. It's a pity that some new magic dependency-building hack isn't standard, just by virtue of the fact that, previously, we had this thing called #include and a mostly standard -I behaviour that we can no longer have for the price of a simple added symlink, or the trivial packaging code to feed --with-lib=/right/here into the %configure via simple %if's. Yeah. Let's get something new and novel, because it's, um, shiny. Let's embrace this year's bad plan because making a rogue project actually work within an established framework is just, um, hard, man. pkg-config is to Build as info(1) is to man(1): an extra project looking to fill a niche manufactured by something other than cooperation with established, reliable and repeatable procedures (and, in Build, we really don't need things to be reliable, repeatable or time-tested - that's so boring!)
You can actually #include <openssl/ssl.h> with no extra -I paths needed from FC1 onwards. Using pkg-config to determine how to compile and link against OpenSSL is still the Right Thing.
Workaround: I won't comment on the merrits of pkg-config, but for normal users that use other people's packages/modules that don't yet use pkg- config here is a workaround. Do this before running configure/make/make install: export CFLAGS="-I/usr/kerberos/include" It may be so simple and seem so obvious that nobody considered writing it here yet. But hey - it worked for me for building apache/httpd and is easier than fiddling with makefiles...
To respond to comment #21 by Peter Valdemar: That's exactly what I'm trying to do, as described in comment #2. It's just not that easy in SRPMs, because a) some packages don't use autoconf; some (even with autoconf) don't respect the CFLAGS/CPPFLAGS environments or make parameters; b) CFLAGS also needs the $RPM_OPT_FLAGS (actually, '-I' belongs in the CPPFLAGS and nowhere else) and other side effects. And you need to adapt each and every package which builds against OpenSSL before rebuilding. I'd still rather have the implicitely required headers in a standard location (e.g. /usr/include, or be it /usr/include/kerberos). Manually, I do exactly as you, adding includes to the CPPFLAGS as required, until it runs through. ;-)
Ha! Even OpenServer 5 got it right. 226$ ls -l /usr/include/openssl/kssl.h -r--r--r-- 1 bin bin 5888 May 13 2004 /usr/include/openssl/kssl.h Yay! I knew the licenses were so expensive for a reason.