Re: conflict between heimdal and umich gssapi library and their consequences

[Russ Allbery <rra@stanford.edu>]

Guillaume Rousse <Guillaume.Rousse@inria.fr> writes:

> Hello. I'm mandriva nfs-utils maintainer, trying to fix a conflict issue
> between heimdal and umich gssapi libraries.

> Both heimdal 1.0.1 and libgssapi include a libgssapi.so.2.0.0 file, with
> different content, triggering a conflict between the two packages: you
> can't install them both under the same prefix.

> On mandriva linux, nfs-utils is built against the last one (more
> precisely: against librpcsecgss, itself built against libgssapi), hence
> preventing installation of heimdal libs on any host with nfs installed.
> Worst, as mandriva build cluster is nfs-based, I can't even install
> rebuild stuff against heimdal itself...

> Debian had the same issue:
> http://lists.debian.org/debian-devel/2007/08/msg00511.html. Apparently,
> they decided to not rename heimdal library (which would solve the
> confict), but instead try to build anything gss-dependant against
> kerberos-provided (mit or heimdal) gss implementation, instead of umich
> one (http://lists.debian.org/debian-devel/2007/07/msg00590.html). I
> guess Debian maintainers are lurking there, so they probably correct me
> if I'm wrong :)

I'm fairly sure that for right now Debian is just living with the problem
and conflicting the libraries.  That makes Heimdal almost unusable in
Debian since the UMich GSS-API indirection layer gets pulled in by the
NFSv4 support, which is part of standard.

I'm still of the opinion that UMich was at fault here and they need to
rename their GSS-API library to something else.  Heimdal was using that
library name first, and regardless of how much more "generic" they think
their indirection layer is, taking a shared library name that's already in
use is frankly rather rude.  Picking a different SONAME version to start
with clearly isn't sufficient, as we now see.

Heimdal could work around this by bumping the Heimdal SONAME version to 3,
but this gets rather silly quickly.

> A quick attempt of mine to build librpcsecgss against something else as
> libgssapi failed, however. Rather than playing with configure script (as
> I don't have much knowledge of gss internals), I'm currently tempted to
> drop gss support from nfs-utils in Mandriva. But maybe is there a better
> solution ?

I'm curious whether nfs-utils would work fine when linked directly with a
real GSS-API implementation, either MIT's or Heimdal's.  The UMich library
adds nothing so far as I know other than the ability to dynamically chose
Kerberos implementations, which given the problems it's causing doesn't
strike me as worth it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>