Re: conflicting gssapi libraries
Aníbal Monsalve Salazar <email@example.com> writes:
> On Sat, Aug 11, 2007 at 07:13:01PM -0700, Russ Allbery wrote:
>> Why? Could you explain what the UMich indirection library practically
>> adds for our users? Why would we want to continue using it rather than
>> linking directly against an appropriate GSSAPI implementation?
> I agree with all that. However, nfs-utils has been developed with the
> UMich gssapi iplementation. I don't know why they decided no to use the
> MIT library.
It may be that they were trying to provide an indirection layer between
MIT and Heimdal so that people could choose whichever they want at
runtime. I'm not sure of another reason for it. The UMich library
doesn't actually implement GSSAPI at all; it requires that another
implementation (MIT or Heimdal) be available and just calls into the other
There are some advantages to having an indirection layer when you want to
experiment with different libraries and see which works better (for
OpenLDAP, for instance, Heimdal has better performance characteristics
than MIT Kerberos), but it causes a lot of problems, particularly with the
same library name as Heimdal's.
I *think* that because it's an indirection layer, the NFS code would work
the same linked directly with a GSSAPI implementation like MIT's or
Heimdal's, but it's possible that they have some bits of code that aren't
purely indirection. This is what I'd need to experiment with to see what
the implications are. Unfortunately, I'm not going to have an opportunity
to set up an NFSv4 test environment to really experiment in the near
> Is it worth it to try to get both upstream authors to unify the
> libraries? Maybe Brian and me could try that.
I think that UMich is currently working with MIT to unify their
implementation with MIT's, although I don't know how fast that's going.
My understanding is that they don't want to maintain that indirection
layer going forward.
> Why the MIT folks renamed their library? I doubt it was because the
> UMich folks used the same library name.
It's always been called libgssapi_krb5 so far as I know. krb5 was the
only GSSAPI mechanism that it provided (now it also provides SPNEGO), so
originaly the name made sense from that perspective.
I don't know the thought process that went into the original name. The
MIT library also provides an indirection layer so that multiple GSSAPI
mechs can be used (and the UMich library ends up calling that indirection
layer and going through multiple indirections).
I'm not sure where this is all going in the long run.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>