Re: conflicting gssapi libraries
http://linux-nfs.org/pipermail/nfsv4/2007-September/006695.html The following message belongs to the thread listed above. Date: Sun, 2 Sep 2007 18:57:24 -0400 From: Kevin Coffman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Russ Allbery [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: conflict between heimdal and umich gssapi library and their consequences On 9/1/07, Russ Allbery [EMAIL PROTECTED] wrote: 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. I regret any inconvenience our libgssapi library has caused. We used the obvious name and had no malicious intent. I will rename our library to libgssglue which will require a change in librpcsecgss and will require nfs-utils to be reconfigured and recompiled (no source changes required). I will put out new versions on Tuesday. I'll package libgssglue and change nfs-utils to depend on libgssglue. K.C. ___ NFSv4 mailing list [EMAIL PROTECTED] http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 On Wed, Aug 15, 2007 at 12:51:13PM +1000, Brian May wrote: So in summary, what is the verdict? I am inclined to add a non-versioned conflicts for now, as I suspect it might be a while before this can be solved in a better way. Also: No, I don't want to maintain a patch in Heimdal that renames the library. If upstream could be convinced to rename the library that would be OK though. Upstream decided to rename the UMich libgssapi library. -- Brian May [EMAIL PROTECTED] Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: conflicting gssapi libraries
On Mon, Sep 03, 2007 at 12:03:47PM +1000, Anibal Monsalve Salazar wrote:
I'll package libgssglue and change nfs-utils to depend on libgssglue.
The {build-,}dependencies of both librpcsecgss and libgssapi are:
source package librpcsecgss
depends:
nfs-common librpcsecgss3
nfs-kernel-server librpcsecgss3
build-depends:
nfs-utils librpcsecgss-dev
source package libgssapi
depends:
nfs-common libgssapi2
nfs-kernel-server libgssapi2
build-depends:
fetchmail libgssapi-dev
librpcsecgss libgssapi-dev
nfs-utils libgssapi-dev (= 0.11)
Best Regards,
Aníbal Monsalve Salazar
--
http://v7w.com/anibal
signature.asc
Description: Digital signature
Re: conflicting gssapi libraries
So in summary, what is the verdict? I am inclined to add a non-versioned conflicts for now, as I suspect it might be a while before this can be solved in a better way. Also: No, I don't want to maintain a patch in Heimdal that renames the library. If upstream could be convinced to rename the library that would be OK though. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ It may be that they were trying to provide an indirection Russ layer between MIT and Heimdal so that people could choose Russ whichever they want at runtime. I'm not sure of another Russ reason for it. The UMich library doesn't actually implement Russ GSSAPI at all; it requires that another implementation (MIT Russ or Heimdal) be available and just calls into the other Russ library. GSSAPI isn't limited to just Kerberos, you could implement other protocols in GSSAPI too. Having said that, the only GSSAPI libraries in Debian I know of are the two Kerberos libraries. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
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? GSSAPI was created to allow the use of multiple authentication mechanisms. If you do not want to allow that, then you should just get rid of GSSAPI completely and use the Kerberos APIs directly, as in this case GSSAPI just adds a lot of unneccessary complexity. Apart from the library naming issue, the UMich library is doing the Right Thing wrt. the original intentions of the GSSAPI. Applications should just depend on the _interface_. The actual implementation selection should be a system-local policy and should not be hard-coded in dependencies. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Gabor Gombas [EMAIL PROTECTED] writes: GSSAPI was created to allow the use of multiple authentication mechanisms. If you do not want to allow that, then you should just get rid of GSSAPI completely and use the Kerberos APIs directly, as in this case GSSAPI just adds a lot of unneccessary complexity. All of the GSSAPI libraries under discussion, MIT and Heimdal included, implement an indirection layer and allow other mechanisms to be plugged in. The only unique part about the UMich library is that it offers nothing other than a mechglue layer, whereas the other implementations provide both a mechglue layer and some specific mechanism implementations. Apart from the library naming issue, the UMich library is doing the Right Thing wrt. the original intentions of the GSSAPI. Applications should just depend on the _interface_. Except that they can't just depend on a generic mechglue layer provided by all possible implementations because the different GSSAPI implementations offer slightly different symbols in areas not covered by the standard but which applications actually use. The actual implementation selection should be a system-local policy and should not be hard-coded in dependencies. I think you're confusing pluggable GSSAPI *mechanisms*, which everyone agrees is a good idea, with pluggable GSSAPI *mechglue*, which is harder and which doesn't offer clear benefits for Debian (at least in my opinion). It feels like one level of indirection too many to me. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Brian May [EMAIL PROTECTED] writes: Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ It may be that they were trying to provide an indirection Russ layer between MIT and Heimdal so that people could choose Russ whichever they want at runtime. I'm not sure of another Russ reason for it. The UMich library doesn't actually implement Russ GSSAPI at all; it requires that another implementation (MIT Russ or Heimdal) be available and just calls into the other Russ library. GSSAPI isn't limited to just Kerberos, you could implement other protocols in GSSAPI too. Yes; the MIT library, for example, implements both a krb5 mechanism and an SPNEGO mechanism, and the Heimdal library implements krb5, SPNEGO, and NTLM. Having said that, the only GSSAPI libraries in Debian I know of are the two Kerberos libraries. No one inside of Debian or out, so far as I know, ships separate mechanism implementations for existing mechglue layers. One reason why not is probably that the maintainers of existing mechglue layers have been happy to include all mechanisms with those layers. Here, here's a table that summarizes my understanding of the situation and may help: Library Mechglue? Mechanisms --- - -- Heimdal yes Kerberos, SPNEGO, NTLM MIT yes Kerberos, SPNEGO UMich libgssapi yes -none- [1] libgssyes Kerberos [2] [1] Requires that some other GSSAPI library be installed and calls into the mechglue layer of *that* library to provide all of its functionality. [2] Uses Shishi for its Kerberos implementation, which is wire-compatible with other Kerberos implementations but not, so far as I know, fully compatible with ticket caches, configuration, and similar local infrastructure. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ My preference would be to dump the UMich GSSAPI library and Russ link nfs-common directly against MIT Kerberos, which doesn't Russ conflict with Heimdal. So should I make the Heimdal GSSAPI library conflict with the UMich GSSAPI library? It which case, does the UMich library also have to conflict with the Heimdal GSSAPI library? I had a feeling I was told the conflicts had to appear in both packages, but I can't remember why right now. Anyway, I see that MIT Kerberos has named their library: /usr/lib/libgssapi_krb5.so.2 Wouldn't this be a better solution then getting rid of the UMich library? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
On Sun, Aug 12, 2007 at 10:40:40AM +1000, Brian May wrote: Russ Allbery [EMAIL PROTECTED] writes: My preference would be to dump the UMich GSSAPI library and link nfs-common directly against MIT Kerberos, which doesn't conflict with Heimdal. No. There is a better solution, Brian has found that the MIT kerberos library was renamed. So should I make the Heimdal GSSAPI library conflict with the UMich GSSAPI library? It which case, does the UMich library also have to conflict with the Heimdal GSSAPI library? I had a feeling I was told the conflicts had to appear in both packages, but I can't remember why right now. Anyway, I see that MIT Kerberos has named their library: /usr/lib/libgssapi_krb5.so.2 So, we only need versioned conflicts. Right? Wouldn't this be a better solution then getting rid of the UMich library? Yes. -- Brian May [EMAIL PROTECTED] Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: conflicting gssapi libraries
Aníbal Monsalve Salazar [EMAIL PROTECTED] writes: On Sun, Aug 12, 2007 at 10:40:40AM +1000, Brian May wrote: Wouldn't this be a better solution then getting rid of the UMich library? Yes. 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? Also, since it was the UMich library that took over a library name that was already in use by Heimdal, if we're going to be renaming upstream libraries (which I think is a little dubious), which library to rename is pretty obvious to me, and it's not the Heimdal one. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: conflicting gssapi libraries
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. Is it worth it to try to get both upstream authors to unify the libraries? Maybe Brian and me could try that. Also, since it was the UMich library that took over a library name that was already in use by Heimdal, if we're going to be renaming upstream libraries (which I think is a little dubious), which library to rename is pretty obvious to me, and it's not the Heimdal one. Why the MIT folks renamed their library? I doubt it was because the UMich folks used the same library name. Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: conflicting gssapi libraries
Aníbal Monsalve Salazar [EMAIL PROTECTED] 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 library. 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 future. :/ 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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
conflicting gssapi libraries
[4 letter words deleted] === cut === # sudo dpkg -i libgssapi2-heimdal_1.0.1-1_i386.deb ──(Fri,Aug10)─┘ Selecting previously deselected package libgssapi2-heimdal. (Reading database ... 188542 files and directories currently installed.) Unpacking libgssapi2-heimdal (from libgssapi2-heimdal_1.0.1-1_i386.deb) ... dpkg: error processing libgssapi2-heimdal_1.0.1-1_i386.deb (--install): trying to overwrite `/usr/lib/libgssapi.so.2.0.0', which is also in package libgssapi2 Errors were encountered while processing: libgssapi2-heimdal_1.0.1-1_i386.deb === cut === [more 4 letter words deleted] This wasn't a problem until just recently because it use to be libgssapi.so.1.0.0 in Heimdal. Solution? -- Brian May [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Fri, Aug 10, 2007 at 09:53:09AM -0700, Russ Allbery wrote: My preference would be to dump the UMich GSSAPI library and link nfs-common directly against MIT Kerberos, which doesn't conflict with Heimdal. If you file a bug against nfs-common with what Build-Depends or other changes you need to make this work, I'd be happy to make the change. Yeah, but figuring out what changes we need is part of the problem -- I'm guessing there's some reason why we didn't go that route in the first place and that it won't just work without some changes, and I have no NFSv4 environment in which to test. I'd be happy to help as much as I can from the Kerberos side, but unfortunately I can't do much beyond expressing a hopeful opinion. :/ BTW, I'm guessing that you actually want libgssapi2 to depend on some GSSAPI implementation; right now, it's possible to install it with no underlying implementation, which generally isn't what you want. nfs-common happens to depend on MIT Kerberos as well so I'm guessing that's pulling in the GSSAPI implementation in the common case. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Brian May [EMAIL PROTECTED] writes: [4 letter words deleted] Yup. The UMich GSSAPI thing causes no end of problems. Thankfully, upstream is working on making it go away; in the meantime, we're going to have a serious problem since installing it at priority standard (which is what's going on right now) essentially makes Heimdal unusable on Debian. Solution? My preference would be to dump the UMich GSSAPI library and link nfs-common directly against MIT Kerberos, which doesn't conflict with Heimdal. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
On Fri, Aug 10, 2007 at 10:25:07AM -0700, Russ Allbery wrote: Yeah, but figuring out what changes we need is part of the problem -- I'm guessing there's some reason why we didn't go that route in the first place and that it won't just work without some changes, and I have no NFSv4 environment in which to test. Well, then we're two. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
On Fri, Aug 10, 2007 at 04:53:32PM +1000, Brian May wrote: [4 letter words deleted] === cut === # sudo dpkg -i libgssapi2-heimdal_1.0.1-1_i386.deb ──(Fri,Aug10)─┘ Selecting previously deselected package libgssapi2-heimdal. (Reading database ... 188542 files and directories currently installed.) Unpacking libgssapi2-heimdal (from libgssapi2-heimdal_1.0.1-1_i386.deb) ... dpkg: error processing libgssapi2-heimdal_1.0.1-1_i386.deb (--install): trying to overwrite `/usr/lib/libgssapi.so.2.0.0', which is also in package libgssapi2 Errors were encountered while processing: libgssapi2-heimdal_1.0.1-1_i386.deb === cut === [more 4 letter words deleted] This wasn't a problem until just recently because it use to be libgssapi.so.1.0.0 in Heimdal. Solution? Persuade Heimdal upstream to provide an soname that uniquely identifies this library in the face of other, pre-existing libgssapi packages, and barring that, add a Debian-specific soname component to it? Or if the libraries are actually fully ABI-compatible, perhaps the two packages could have the same Provides that could be used in the shlibs? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
Steve Langasek [EMAIL PROTECTED] writes: Persuade Heimdal upstream to provide an soname that uniquely identifies this library in the face of other, pre-existing libgssapi packages, and barring that, add a Debian-specific soname component to it? That's a bit unfair to Heimdal given that their GSSAPI library predates the UMich library by many years. Or if the libraries are actually fully ABI-compatible, perhaps the two packages could have the same Provides that could be used in the shlibs? This may work. They both implement the same standard. Although they're not *fully* ABI-compatible, since Heimdal exposes some additional symbols that are useful for users who are doing Kerberos, so it probably won't work as-is. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conflicting gssapi libraries
On Fri, Aug 10, 2007 at 09:53:09AM -0700, Russ Allbery wrote: My preference would be to dump the UMich GSSAPI library and link nfs-common directly against MIT Kerberos, which doesn't conflict with Heimdal. If you file a bug against nfs-common with what Build-Depends or other changes you need to make this work, I'd be happy to make the change. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
