With libnegotiateauth.so packaged with installer builds, I'm seeing the following error running regxpcom: nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with error: libcom_err.so.3: cannot open shared object file: No such file or directory I have libcom_err.so.2, but not .3 on my system. I have Fedora Core 1. Fedora-devel (and probably FC2) also ships with the older version of the library. The message gets printed 3 times while running the installer, but it's not printed when actually running Mozilla.

I'm seeing the exact same thing - I have .2 but not .3 on my Debian testing box.

this makes us look bad and we are apparently distributing an extension nobody can use.

ah. libcom_err.so.3 is part of the krb5-libs-1.2.x package on older Red Hat versions (how ridiculous). But it's not part of the krb5-libs package for Fedora Core 1 or Fedora devel (yay!).

-> Build Config I'm presuming that fixing this bug is a matter of configuring the build systems properly... whatever properly means.

Is it time for the annual 'explicitly list external dependencies' vs running 'out of the box' debate? The bug should be marked invalid unless we claim to run 'out of the box' on every Linux distribution available, which I don't believe we do. Assuming that we're not talking about a static build here (default seamonkey), linking against the static versions of the krb5 libs is out of the question unless we want to revisit that 'linking non-PIC static libs into a shared library' issue. Btw, if anyone's wondering how Fedora managed to drop a major shared library version on libcom_err, the krb5-libs package started using the version of libcom_err that comes with e2fsprogs instead of bundling their own. I don't think it's possible for us to use the older version with the current version of krb5 on the release machine.

> Is it time for the annual 'explicitly list external dependencies' vs running > 'out of the box' debate? The bug should be marked invalid unless we claim to > run 'out of the box' on every Linux distribution available, which I don't > believe we do. If this can't work, fine. If it does work, great. I just don't think it's good to have scary messages printed out every time people install a build.

(In reply to comment #5) > The bug should be marked invalid unless we claim to > run 'out of the box' on every Linux distribution available, This bug does not cause Mozilla not to run, right? It just makes negotiateauth unavailable?

yes, Mozilla runs fine.

Same problem with Debian (Sid). Of course I tried the version of today (5.5.)

*** Bug 242795 has been marked as a duplicate of this bug. ***

note that darin filed bug 243870 which would 'silence' the 'error'. i'm a bit confused. is it impossible for our negotiate auth code to try dynamically loading symbols from libcom_err.so.2/libcom_err.so.3?

I didn't think the negotiate auth code used libcom_err directly. I thought it was a (explicit) shared library dependency from linking against -lkrb5. Besides that, what happens if somoene builds against a version of krb5 which uses yet another version of libcom_err or they statically link against a special version of those libs built with -fPIC? I don't see the point of duplicating the work of the dynamic loader to hide an additional library dependency. We should state the dependency explicitly.

Just for information purposes, I get this same bug on SuSE 9.0 Porfessional and on the latest SuSE 9.1 Porfessional.

With SuSE Linux 8.2 and Mozilla 1.7rc2 the error message appears for the .2 version: nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with error: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory bug 243870 seems to downplay this as an "insignificant error", but if it is, it still has an effect: the application is not launched after installation. In previous releases it always was, and I believe this was required. On a Linux system, you normally install it as user root and should run it once, and then of course you run it as a nonprivileged user. Now, the run-as-root-once has to be done manually. (not sure if these are related, maybe it isn't automatically started anyway)

Additional information. SuSE 9.0 and 9.1 Professional use the heimdal-lib package for the kerberos libraries. rpm -q --info heimdal-lib Name : heimdal-lib Relocations: /usr Version : 0.6 Vendor: SuSE Linux AG, Nuernberg, Germany Release : 67 Build Date: Tue 23 Sep 2003 04:32:24 PM EDT Install date: Tue 17 Feb 2004 12:20:34 PM EST Build Host: F12.suse.de Group : System/Libraries Source RPM: heimdal-0.6-67.src.rpm Size : 916788 License: BSD, Other License(s), see package Signature : DSA/SHA1, Tue 23 Sep 2003 04:34:57 PM EDT, Key ID a84edae89c800aca Packager : http://www.suse.de/feedback URL : http://www.pdc.kth.se/heimdal/ Summary : Free Kerberos5 implementation - libraries Description : Heimdal is a free implementation of Kerberos5 available from http://www.pdc.kth.se/src/heimdal-devel, also the home of KTH-Krb -- a free implementation of Kerberos4. Heimdal is maintained and produced in Sweden (outside the US!), is in the public domain in the sense of the Wassenaar agreement, and is freely exportable. Authors: -------- heimdal@pdc.kth.se Distribution: SuSE Linux 9.0 (i586)

> bug 243870 seems to downplay this as an "insignificant error", but if it is, it > still has an effect: the application is not launched after installation. this is by design and not related to the error. > In previous releases it always was, and I believe this was required. > On a Linux system, you normally install it as user root and should run it once, > and then of course you run it as a nonprivileged user. the installer now does what is necessary without actually running Mozilla by running regxpcom and regchrome (bug 57089)

(In reply to comment #14) > still has an effect: the application is not launched after installation. No. This message can not be related to that.

*** Bug 247513 has been marked as a duplicate of this bug. ***

(In reply to comment #5) > Is it time for the annual 'explicitly list external dependencies' vs running > 'out of the box' debate? The bug should be marked invalid unless we claim to > run 'out of the box' on every Linux distribution available, which I don't > believe we do. I would like to to know on which platforms/OS versions does negotiateauth work out of the box? Obviously we would like to reach the biggest community possible, while not discouraging users from upgrading their kerberos libraries to newer versions (there are often security sensitive fixes with every release). Will negotiateauth continue to function if a user upgrades to the newest MIT kerberos libraries? At least version 1.3.1 is needed for good compatibility with Active Directory. I'm going to send a note to the MIT kerberos mailing list and get their thoughts on which version of MIT kerberos we should build on for greatest binary compatiblity and AD Support.

Response from MIT kerberos list http://diswww.mit.edu:8008/menelaus.mit.edu/kerberos/21944 It sounds like that if we upgraded and compiled against RedHat's 1.3x builds we would probably break compatiblity with every other linux distribution's MIT libraries (unless they followed suit and did the same thing, for whatever reason).

I'm thinking that it might make sense to dlopen the GSSAPI libraries instead of linking to them at build time. That might enable us to handle a greater variety of GSSAPI installations.

bryner had a good idea. why not only link to libgssapi_krb5.so? it seems to work on linux, as all of the symbols we use are contained in that library. the other libraries get loaded at runtime, but they are loaded based on what libgssapi_krb5.so needs, not based on what our libnegotiateauth.so needs.

(In reply to comment #22) > bryner had a good idea. why not only link to libgssapi_krb5.so? it seems to > work on linux, as all of the symbols we use are contained in that library. the > other libraries get loaded at runtime, but they are loaded based on what > libgssapi_krb5.so needs, not based on what our libnegotiateauth.so needs. I liked the dlopen idea in the long run because we could theoretically could get compatiblity for every GSSAPI implementation in 1 build. How close to this could we get with just linking in the one library?

> I liked the dlopen idea in the long run because we could theoretically could get > compatiblity for every GSSAPI implementation in 1 build. How close to this > could we get with just linking in the one library? If we link just one library, then the name of that library matters. It seems to me that the library name varies depending on the gssapi implementation. Using dlopen, we could try to load several different libraries. Optionally, we could also avoid #include'ing any gssapi headers. But, do we know for sure that every gssapi implementation exports the same base set of symbols? What is the name of the gssapi library provided by heimdal? As a quick fix for mozilla 1.7.2 and firefox 1.0, I'll probably just land the change that bryner was suggesting. I think Mozilla.org's main target should probably be compatibility with different versions of MIT krb5 shipped by supported versions of RedHat Linux and Mac OSX.

This is the list of files in heimdal. The gssapi lib names are libgssapi.so.1 and libgssapi.so.1.4.0. libgssapi.so.1 is a sym link to libgssapi.so.1.4.0. $ rpm -ql heimdal-lib /etc/krb5.conf /usr/lib/libasn1.so.6 /usr/lib/libasn1.so.6.0.2 /usr/lib/libgssapi.so.1 /usr/lib/libgssapi.so.1.4.0 /usr/lib/libhdb.so.7 /usr/lib/libhdb.so.7.0.7 /usr/lib/libkadm5clnt.so.4 /usr/lib/libkadm5clnt.so.4.2.4 /usr/lib/libkadm5srv.so.7 /usr/lib/libkadm5srv.so.7.0.6 /usr/lib/libkafs.so.0 /usr/lib/libkafs.so.0.4.0 /usr/lib/libkrb5.so.17 /usr/lib/libkrb5.so.17.3.0 /usr/lib/libotp.so.0 /usr/lib/libotp.so.0.1.4 /usr/lib/libroken.so.16 /usr/lib/libroken.so.16.0.3 /usr/lib/libsl.so.0 /usr/lib/libsl.so.0.1.2

FWIW: I'm running Mandrake 10 and after installing negotiateauth and restarting Mozilla I get: nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with error: libstdc++.so.3: cannot open shared object file: No such file or directory Versions used: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7b) Gecko/20040316 libkrb51-1.3-6.2.100mdk krb5-workstation-1.3-6.2.100mdk libstdc++2.10-2.96-0.83mdk libstdc++5-3.3.2-6mdk libext2fs2-1.34-5mdk (supplies libcom_err.so)

(In reply to comment #26) > FWIW: I'm running Mandrake 10 and after installing negotiateauth and restarting > Mozilla I get: What do you mean after installing negotiateauth? It's standard in Mozilla 1.7 final (It may have been in the 1.7B but I don't think the parsing URL's worked very well, so I wouldn't use it). Try just downloading 1.7 Final and at least that problem should go away, but you might still have problems with libcommerr.

I've installed 1.7 parallel to the 1.7b. Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7) Gecko/20040616 Is that Final? None of them lists negotiateauth as a plug-in. Should it? I installed negotiateauth from this site: http://negotiateauth.mozdev.org/installation.html

(In reply to comment #28) > I've installed 1.7 parallel to the 1.7b. > Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7) Gecko/20040616 > Is that Final? I think so. > None of them lists negotiateauth as a plug-in. Should it? No, its not a browser plugin its an extention so it won't be listed. It will be there by default. To prove it do a find for libnegotiateauth.so in your Mozilla 1.7 install directory. Also in 1.7 if it fails to load it will do it silently, it will not give you an error message, it just won't work. > I installed negotiateauth from this site: > http://negotiateauth.mozdev.org/installation.html There is no reason to use the installation files from that site anymore, all of that code plus additional bug fixes is already included with Mozilla. If you have additional problems post to Mozillazine forums or Mozilla-security mailing list for support. I will answer your questions from there, bugzilla isn't the place for support questions.

Here's the simplest patch that makes us not link directly with libcom_err.so in the MIT release. This should solve the problem for system's with a version of the MIT krb5 release that is newer than the one Mozilla was compiled against (either the version that ships with RH7.x or RH8, depending on the Mozilla Foundation build system that is used).

Darin: I have tested this patch on AIX and it works fine.

Comment on attachment 153903 [details] [diff] [review] v1 patch this is a nice safe patch that would be good to have on the 1.7 branch

this is needed on the aviary 1.0 branch too. fixed-on-trunk

Comment on attachment 153903 [details] [diff] [review] v1 patch a=mkaply

fixed1.7.3

Comment on attachment 153903 [details] [diff] [review] v1 patch would be good to get this on the aviary 1.0 branch...

Comment on attachment 153903 [details] [diff] [review] v1 patch a=asa for checkin to aviary.