Bug 82369 - ssl.h includes kssl.h which includes (not in /usr/include) krb5.h
ssl.h includes kssl.h which includes (not in /usr/include) krb5.h
Status: CLOSED WONTFIX
Product: Red Hat Public Beta
Classification: Retired
Component: openssl (Show other bugs)
phoebe
i386 Linux
low Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 84331 86471 91865 98224 (view as bug list)
Depends On:
Blocks: 111301
  Show dependency treegraph
 
Reported: 2003-01-21 13:02 EST by ctm
Modified: 2005-10-31 17:00 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-10 23:37:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description ctm 2003-01-21 13:02:23 EST
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).
Comment 1 Nalin Dahyabhai 2003-02-10 23:37:51 EST
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.
Comment 2 Moritz Barsnick 2003-02-17 05:39:32 EST
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
Comment 3 Joe Orton 2003-02-20 08:52:50 EST
*** Bug 84331 has been marked as a duplicate of this bug. ***
Comment 4 Joe Orton 2003-03-25 18:27:33 EST
*** Bug 86471 has been marked as a duplicate of this bug. ***
Comment 5 Henrik Nordstrom 2003-03-25 19:52:52 EST
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..
Comment 6 Brian O'Berry 2003-04-21 08:26:22 EDT
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.
Comment 7 Bishop Clark 2003-04-24 22:52:40 EDT
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.
Comment 8 Joe Orton 2003-05-13 10:50:15 EDT
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.
Comment 9 Henrik Nordstrom 2003-05-13 12:01:24 EDT
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.
Comment 10 Nalin Dahyabhai 2003-05-13 14:39:30 EDT
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.
Comment 11 matti aarnio 2003-05-13 15:03:51 EDT
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

])
Comment 12 Brian O'Berry 2003-05-14 14:39:18 EDT
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. 
 
Comment 13 Nalin Dahyabhai 2003-05-15 14:54:07 EDT
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.
Comment 14 Joe Orton 2003-06-20 12:39:44 EDT
*** Bug 91865 has been marked as a duplicate of this bug. ***
Comment 15 Joe Orton 2003-07-09 15:50:50 EDT
*** Bug 98224 has been marked as a duplicate of this bug. ***
Comment 16 Martin Norback 2003-07-09 16:39:55 EDT
If pkg-config is needed to build with openssl, I suggest that the openssl-devel
package gets a

Requires: pkgconfig
Comment 17 Joe Orton 2004-02-04 09:20:11 EST
*** Bug 99313 has been marked as a duplicate of this bug. ***
Comment 18 Henrik Nordstrom 2004-03-06 10:20:11 EST
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.
Comment 19 Bishop Clark 2004-03-14 03:05:48 EST
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!)
Comment 20 Joe Orton 2004-03-14 14:51:04 EST
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.
Comment 21 Peter Valdemar Mørch 2004-03-19 09:39:11 EST
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...
Comment 22 Moritz Barsnick 2004-03-19 09:51:35 EST
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. ;-)
Comment 23 Bishop Clark 2005-01-08 06:00:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.