missing symlinks break binary compatibility with native upstream components

Bug #244439 reported by Alexander Sack on 2008-07-01
44
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
Medium
nspr (Ubuntu)
High
Alexander Sack
Hardy
High
Alexander Sack
Intrepid
High
Alexander Sack
nss (Ubuntu)
High
Alexander Sack
Hardy
High
Alexander Sack
Intrepid
High
Alexander Sack

Bug Description

the .so symlinks currently shipped in libnss-dev and libnspr-dev should go to the main binary package to unbreak binary compatibility with upstream components.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=442257 - "Weave 1.32: WeaveCrypto doesn't work under Linux"
See: https://bugzilla.mozilla.org/show_bug.cgi?id=442788 - "WeaveCrypto doesn't work under Linux"

SRU test:

Please test the following:

 1. install weave extension on top of the latest firefox in hardy-updates; reproduce that you cannot log-in
 2. upgrade the nspr/nss packages from hardy-proposed
 3. restart browser
  3a. if weave login works all fine (let us know)
  3b. if weave login still doesnt work, please uninstall the weave extension, stop firefox, and install the weave extension again.

Two things would help to diagnose the problem:

1) Go to Tools->Error Console, and enter the following in the "Code"
textbox at the top (as one line) and press enter. It will add a line of output to the error console, eg "x86-gcc3"

    Components.classes["@mozilla.org/xre/app-info;1"]
      .getService(Components.interfaces.nsIXULRuntime).XPCOMABI

2) Create a new profile, install Weave, exit Firefox. Then delete *.dat and extensions.cache from your profile, and launch firefox via:

    strace -f firefox > ~/stracelog.txt 2>&1

   Let Firefox come up, then quit. You may need to Control-C in the terminal to end the strace. Attach the stracelog.txt here (note that if you didn't start with a clean profile, there could be sensitive data in the trace).

Actually, a 3rd thing might be useful too.

3) cd to your profile, then cd to extensions/{340c2bbc-ce74-4362-90b5-7c26312808ef}/platform/Linux_x86-gcc3/components/ and run:

    ldd WeaveCrypto.so

Attach output here.

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

So, taking a cue from asac's question in bug 442257 comment 22, I did a clean install of Hardy into a VM (and updated it), but did *not* install anything else (such as the dev packages needed for building FF from source).

In that environment, I'm now able to reproduce the Weave failure. stracing the browser startup shows us the linker trying to find libnspr4.so in various places but failing. sigh.

There *is* a /usr/lib/libnspr4.so.0d, but I'm not sure if we should be linking against that. Have to look closer at what that is, and since Firefox on Ubuntu is a xulrunner all if we should be linking against all the other stuff at all (isn't libxul supposed to have it all?). Investigating...

Hmm. Yeah, we do seem to need to link against libnspr and friends. Otherwise building the component fails.

On the VM where I can reproduce the problem, "ldd WeaveCrypto.so" reports that it can't find libxpcom.so, libnspr4.so, libsmime3.so, libssl3.so, libnss3.so, libnssutil3.so, libplds4.so, and libplc4.so. On my build machine, these are all found in /usr/lib (presumably put there by the build-dep packages I have installed). [Well, libxpcom.so isn't found but it works anyway; I guess the xpcomglue_s that's linked in is taking care of this at runtime?]

I also found: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/228032

...which makes me suspect this is a Debian/Ubuntu bug. And I found bsmedberg's old "Debian Versioning of Mozilla Libraries Harmful" blog post, which also makes me wonder just what's supposed to be happening here. :/

Suggestions? Does Weave need to link differently, or is this a Ubuntu bug?

Created attachment 327523
ldd WeaveCrypto.so - Firefox 3 (x86-gcc3) Ubuntu 8.04.1 (Hardy)

The ldd output is misleading. What you want to run is

LD_LIBRARY_PATH=/path/to/firefox/installation ldd WeaveCrypto.so

Ubuntu doesn't play the nasty debian versioning games, as far as I know, so you should have a /usr/lib/firefox-3.0/libxpcom.so and so forth.

Not so sure about NSPR, but it should be able to find libnspr4.so from the Firefox installdir or from /usr/lib

My strace.log is 5718 kilobytes (KB) in size, too big for a non-patch file
attachment.

Should I send it as a patch?

No, please bzip2 it and then attach it.

Created attachment 327524
stracelog.txt - Firefox 3 (x86-gcc3) Ubuntu 8.04.1 (Hardy)

Created attachment 327526
ldd with LD_LIBRARY_PATH

(In reply to comment #7)
> The ldd output is misleading. What you want to run is
>
> LD_LIBRARY_PATH=/path/to/firefox/installation ldd WeaveCrypto.so

Same result, not found.

The relevant portion is

[pid 7190] open("/lib/tls/i686/cmov/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/tls/i686/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/tls/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/tls/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i686/cmov/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i686/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/i486-linux-gnu/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i486-linux-gnu/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)

This means that ubuntu is not shipping with the standard NSPR libraries, either as system-NSPR or as local-to-Firefox NSPR. This is a bug in Ubuntu. Mconnor/blizzard, can one of you make contact with them? Not having a unified way to ship plugin libraries is a pretty big deal in terms of the Firefox branding.

That might already be covered by the bug I noted in comment 5 (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/228032). Blah.

Despite the "nasty debian versioning games" (which only exist for nspr and nss nowadays), I bet this doesn't fail on debian. Because I've always be careful that libnspr4.so and friends are symlinks to the versioned libraries. And while the burden was on iceweasel before, the symlinks are now provided by nspr and nss themselves. So to fix this, Ubuntu just needs to "take back" from debian.
As for Ubuntu users, they can certainly install libnspr and libnss from debian, and be happy.

Ben, maybe you should take a look at recent debian packages before speaking.

Please install libnspr4-dev and libnss3-dev in ubuntu. If it helps let me know and we will get the fix really soon.

btw, why dont we use bug #442257 which was used to get things started?

Alexander Sack (asac) wrote :

the .so symlinks currently shipped in libnss-dev and libnspr-dev should go to the main binary package to unbreak binary compatibility with upstream components.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=442257 - "Weave 1.32: WeaveCrypto doesn't work under Linux"
See: https://bugzilla.mozilla.org/show_bug.cgi?id=442788 - "WeaveCrypto doesn't work under Linux"

Changed in nss:
importance: Undecided → High
status: New → Triaged
assignee: nobody → asac
importance: Undecided → High
status: New → Triaged
assignee: nobody → asac

Created https://launchpad.net/bugs/244439 to track this issue.

I installed libnspr4-dev and libnss3-dev in ubuntu 8.04 and it seems to have worked. I tried weave with a stock firefox3.0 from getfirefox.com before that.

Please verify that installing the following packages fix this for you (assuming 32-bit) - with and without -dev packages:

NSPR: http://launchpadlibrarian.net/15727099/libnspr4-0d_4.7.1%2B1.9-0ubuntu0.8.04.2%7Emt1_i386.deb

NSS: http://launchpadlibrarian.net/15726878/libnss3-1d_3.12.0.3-0ubuntu0.8.04.1%7Emt1_i386.deb

If you have the -dev packages installed either remove them before installing them or install the latest as well:

NSPR: http://launchpadlibrarian.net/15726882/libnss3-dev_3.12.0.3-0ubuntu0.8.04.1%7Emt1_i386.deb

NSS: http://launchpadlibrarian.net/15727100/libnspr4-dev_4.7.1%2B1.9-0ubuntu0.8.04.2%7Emt1_i386.deb

Thanks!

Removing the -dev packages wouldn't allow me to login. Installing those newer non -dev versions fixed the problem tho. wierd...

OK, will take this bug and keep you updated on the progress on ubuntu here too. Would appreciate if I get other confirms that the packages from comment 19 fix this.

Changed in nspr:
assignee: nobody → asac
importance: Undecided → High
status: New → Triaged
assignee: nobody → asac
importance: Undecided → High
status: New → Triaged
Alexander Sack (asac) wrote :

proposed fix (see bzr hardy branch) available in ~mozillateam hardy PPA. See https://bugzilla.mozilla.org/show_bug.cgi?id=442788#c19 for links to i386 packages.

Alexander Sack (asac) wrote :

I uploaded the intrepid packages to https://edge.launchpad.net/~mozillateam/+archive too - for the sake of completeness.

Alexander Sack (asac) wrote :

uploaded proposed fix to intrepid: nspr_4.7.1+1.9-0ubuntu2_source.changes

Changed in nspr:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nss - 3.12.0.3-0ubuntu2

---------------
nss (3.12.0.3-0ubuntu2) intrepid; urgency=low

  * move non-versioned .so-links from libnss3-dev package to unbreak
    binary compatibility to native extensions built against upstream
    xulrunner; in turn we add versioned Conflicts: Replaces: on libnss3-dev
    for the libnss3-1d package to allow a seemingly upgrade. (LP: #244439)
    - add debian/libnss3-1d.links
    - update debian/libnss3-dev.links
    - update debian/control

 -- Alexander Sack <email address hidden> Tue, 01 Jul 2008 11:49:00 +0200

Changed in nss:
status: Triaged → Fix Released
Alexander Sack (asac) wrote :

uploaded proposed fix to intrepid - nss_3.12.0.3-0ubuntu2_source.changes

Changed in nss:
status: Fix Released → Fix Committed
status: Fix Committed → Fix Released

proposed fix uploaded to ubuntu development release (intrepid):
 - nspr_4.7.1+1.9-0ubuntu2_source.changes
 - nss_3.12.0.3-0ubuntu2_source.changes

(In reply to comment #22)
> proposed fix uploaded to ubuntu development release (intrepid):

Any chance to see this in Hardy as well?

Alexander Sack (asac) wrote :

SRU process initiated. This is a high impact bug that needs to be fixed in hardy asap.

The proposed fixes are available in the stable packaging branches:

 - https://code.edge.launchpad.net/~mozillateam/nspr/nspr.hardy
 - https://code.edge.launchpad.net/~mozillateam/nss/nss.hardy

and in the mozillateam ppa (https://edge.launchpad.net/~mozillateam/+archive)

 - nspr - 4.7.1+1.9-0ubuntu0.8.04.2~mt1
 - nss - 3.12.0.3-0ubuntu0.8.04.1~mt1

(In reply to comment #23)
> (In reply to comment #22)
> > proposed fix uploaded to ubuntu development release (intrepid):
>
> Any chance to see this in Hardy as well?
>

Stable Release Update (SRU) process initiated. See comment on launchpad bug:

  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/nss/+bug/244439/comments/6

If everything goes well this usually takes about a week.

You can help by following up in LP bug once we call for testing there. Ill drop a note here as soon as the test bits are available.

Alexander Sack (asac) wrote :

nspr_4.7.1+1.9-0ubuntu0.8.04.2_source.changes uploaded to hardy-proposed (awaiting archive approval).

Changed in nspr:
status: Triaged → In Progress
Alexander Sack (asac) wrote :

nss_3.12.0.3-0ubuntu0.8.04.1_source.changes uploaded to ubuntu/hardy-proposed (awaiting approval)

Changed in nss:
status: Triaged → In Progress

(In reply to comment #21)
> OK, will take this bug and keep you updated on the progress on ubuntu here too.
> Would appreciate if I get other confirms that the packages from comment 19 fix
> this.
>
After upgrading from Weave 0.1.30 to 0.2.0 (Ubuntu 8.04, 32-bit system) the passphrase was not accepted. I used the fix from comment 19: uninstalling the libnspr4-dev and libnss3-dev packages, then installing the ones from the link; rebooting. It didn't help (tried several reboots).

Then I deleted the "weave" folder from my Firefox profile. After that it worked.

So I can't tell if it would have worked without the comment 19 fix (maybe deleting the folder would have been good enough from the beginning).

tried the suggested fix, but could not get it to work on my amd64 system hardy 8.04 (the packages are i386)

anyone knows another fix for amd64

Thanks

Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nspr:
status: In Progress → Fix Committed
Changed in nss:
status: In Progress → Fix Committed

(In reply to comment #26)
> tried the suggested fix, but could not get it to work on my amd64 system hardy
> 8.04 (the packages are i386)
>
> anyone knows another fix for amd64
>

Not sure if weave is available for amd64. If so, try to get the latest _hardy_ packages for nss and nspr from the mozillateam PPA: https://edge.launchpad.net/~mozillateam/+archive

Update: the packages have entered hardy-proposed. To test them go to Administration -> Software Sources and enable the Pre-released updates option; then upgrade your system.

Darren Worrall (dazworrall) wrote :

I had to remove --purge and reinstall the packages, rather than simply upgrade, before it (weave) would work. After that it was fine.

Mike Rushton (leftyfb) wrote :

Same here. Had to remove --purge the packages, reinstall as well as delete the entire Firefox profile before it would work.

Martin Pitt (pitti) wrote :

Thank you for testing! Marking as verification-failed, and reopening the bug. It should not be necessary to purge and reinstall the package to fix this, an auto-upgrade should do everything required.

Changed in nss:
status: Fix Released → In Progress
status: Fix Committed → In Progress
Changed in nspr:
status: Fix Committed → In Progress
status: Fix Committed → In Progress
Alexander Sack (asac) wrote :

If the links are in place after this upgrade, all should be fine. Mike, Otacon, have you tried to reinstall weave extension before purging everything?

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

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

Alexander Sack (asac) wrote :

ok, i resurrected this upload as i dont see that the replies given above show that the problem is in the nss/nspr upgrade.

Please test the following:

 1. install weave extension on top of the latest firefox in hardy-updates; reproduce that you cannot log-in
 2. upgrade the nspr/nss packages from hardy-proposed
 3. restart browser
  3a. if weave login works all fine (let us know)
  3b. if weave login still doesnt work, please uninstall the weave extension, stop firefox, and install the weave extension again.

let us know.

If you cant get it to work with the steps above, please post the output of dpkg -L libnss3-1d and dpkg -L libnspr4-0d and check that all files listed there exist on your system.

Thanks!

description: updated
Darren Worrall (dazworrall) wrote :

Was just stepping through it Alex, and you are indeed right, apologies :)

I loaded a Vanilla Hardy VM, patched it up, install Weave, attempted a logon and it failed.

I then upgraded nspr/nss with the packages in proposed.

I immediately tried to login to weave again but got the same error.

I uninstalled/reinstalled weave (restarting FF as unnecessary) , and it logged in straight away. I didnt have to delete the Firefox profile, nor the weave directory in it, and neither was a --purge necessary.

Apologies again for the confusion.

The updates have fixed the problem, but required an uninstall/reinstall of the Weave plugin. Not sure if that's a bug in Weave or FF... if it's even a bug at all! Thought it worth mentioning.

After having installed the latest releases of nspr_4.7.1+1.9 and nss_3.12.0.3 through the repository, it still didn't work for me.
Neither a restart, nor deleting the weave user directory worked for me.

Finally a reinstall of the weave-plugin did the trick!

Thank you guys!

Alexander Sack (asac) wrote :

Thanks for clarifying.

If you can easily resurrect the vanilla Hardy VM, could you also redo the test and run

 sudo touch /usr/lib/xulrunner-1.9/.autoreg

(or sudo touch /usr/lib/firefox-3.0/.autoreg)

right _before_ step 3 (e.g. before restart)?

Does that auto-fix weave for you?

Changed in xulrunner:
status: Unknown → In Progress

Precompiled weave-0.2.0 with 64 bit support -> https://bugzilla.mozilla.org/attachment.cgi?id=327774 ;-) From bug 442679
:-)

I reproduced the steps of the comment:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/244439/comments/14

To succesfully loign i had to remove the weave extension and reinstall it. Then it worked.

I upgraded the following packages from the proposed repository (without removing or purging those installed by the official repository):

libnss3-1d 3.12.0.3-0ubuntu0.8.04.1
libnss3-dev 3.12.0.3-0ubuntu0.8.04.1
libnspr4-0d 4.7.1+1.9-0ubuntu0.8.04.2
libnspr4-dev 4.7.1+1.9-0ubuntu0.8.04.2

Hope this help

Darren Worrall (dazworrall) wrote :

Hi Alex,

After reproducing the error, I left the browser open while I upgraded the packages, a touched the files in turn (xulrunner first, firefox second) - neither fixed the problem (same crypto error each time).

Restarting the browser *did* fix the problem though, I didnt need to reinstall the Weave plugin like previously.

Darren Worrall (dazworrall) wrote :

Couple of other points I thought worth clarifying:

* Installing the updated packages before Weave allows it to function fine, first time.

* Touching *only* /usr/lib/xulrunner-1.9/.autoreg fixes the issue without reinstalling Weave (though after restarting FF)

* Touching *only* /usr/lib/xulrunner-1.9/.autoreg also fixes the issue without reinstalling Weave (though after restarting FF)

* Touching *neither* doesn't work, and requires Weave to be reinstalled before it will work.

HTH

Darren Worrall (dazworrall) wrote :

Whoops, small mistake - the second path should read /usr/lib/firefox-3.0/.autoreg

Alexander Sack (asac) wrote :

Thanks for exploring all the corners of this bug.

For me what you describe is expected behaviour for this fix and should be good enough to go ahead.

Alexander Sack (asac) wrote :

Note: i dont think that touching the application .autoreg files from withing the libraries .postinst is an acceptable option. Especially, when considering that the next xulrunner/firefox security update will auto cure those that dont try to reinstall their extension with blacklisted binary components anyway.

Alexander Sack (asac) wrote :

based on previous comments setting to fix released for intrepid.

Changed in nspr:
status: In Progress → Fix Released
Changed in nss:
status: In Progress → Fix Released
Alexander Sack (asac) wrote :

and fix committed for the hardy SRU.

Changed in nspr:
status: In Progress → Fix Committed
Changed in nss:
status: In Progress → Fix Committed
Alexander Sack (asac) wrote :

nspr upgrade appears to cause problems for installs that still have libnspr4 installed (<=feisty).

See bug 245122

I will upload a new revision to address this.

Alexander Sack (asac) wrote :

nspr failed verification. setting back to in progress. fix coming soonish.

Changed in nspr:
status: Fix Released → In Progress
status: Fix Committed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nspr - 4.7.1+1.9-0ubuntu3

---------------
nspr (4.7.1+1.9-0ubuntu3) intrepid; urgency=low

  * LP: #245122 - fix upgrade issue introduced by "unbreak binary
    compatibility" upload by adding Conflicts/Replaces on libnspr4 (<< 4)
    - update debian/control

nspr (4.7.1+1.9-0ubuntu2) intrepid; urgency=low

  * unbreak binary compatibility for extensions built against upstream
    xulrunner by moving /usr/lib/.so links from libnspr4-dev package
    to libnspr4-0d; in turn we introduce versioned to Conflicts/Replaces
    to provide a smooth upgrade. (LP: #244439)
    - update debian/libnspr4-0d.install
    - update debian/libnspr4-dev.install
    - update debian/control

 -- Alexander Sack <email address hidden> Wed, 09 Jul 2008 21:41:01 +0200

Changed in nspr:
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nspr:
status: In Progress → Fix Committed
Alexander Sack (asac) wrote :

given the nature of the changes in last upload, I'd consider this verification-done unless we get reports that this upgrade breaks something.

Darren Worrall (dazworrall) wrote :

Confirmed everything still works the same as per the first version of this fix (so far as Weave is concerned).

Alexander Sack (asac) wrote :

unfortunately verification failed because of comments in bug 245122 ... reinitating SRU procedure.

Changed in nspr:
status: Fix Committed → In Progress
Alexander Sack (asac) wrote :

same for nss

Changed in nss:
status: Fix Committed → In Progress
Alexander Sack (asac) wrote :

uploading nspr_4.7.1+1.9-0ubuntu0.8.04.4_source.changes nss_3.12.0.3-0ubuntu0.8.04.3_source.changes to hardy-proposed.

Justin Dugger (jldugger) wrote :

So given that Weave is not handing out accounts at the moment, how do I test this?

Paul Gideon Dann (pdgiddie) wrote :

The eBay Companion for Firefox is also affected by this. Basically, anything with a binary component:
https://addons.mozilla.org/en-US/firefox/addon/5202

Darren Worrall (dazworrall) wrote :

Justin - You can use it with any WebDAV host.

Justin Dugger (jldugger) wrote :

Unfortunately, the latest release hard codes a check to services.mozilla.com to see if accounts are available, so neither the reference server nor webDAV will work. I'm told it's fixed in VCS.

James Cuzella (trinitronx) wrote :

I also ran into the issue with no more accounts being available :(. Too bad the new version had to wipe the old accounts off.

After seeing that this fix for Ubuntu went into hardy-proposed, I was hoping to test the x86_64 build of weave in bug #442679 at mozilla bugs with this. Oh well.. guess I have to wait. In the meantime, I'm going to uninstall weave for now to do away with the wizard popup every time I open my browser :P

Reference for others wishing to test...
Precompiled x64 .xpi in:
Bug: "Weave doesn't work on 64-bit Linux systems"
https://bugzilla.mozilla.org/show_bug.cgi?id=442679

Steve Langasek (vorlon) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nspr:
status: In Progress → Fix Committed
Changed in nss:
status: In Progress → Fix Committed
Alexander Sack (asac) wrote :

i verified that upstream firefox build works with the latest nss package in proposed. should be good enough to go for verification-done.

Alexander Sack (asac) wrote :

verified for nspr as well. all done.

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in nspr:
status: Fix Committed → Fix Released
Changed in nss:
status: Fix Committed → Fix Released

Based on comment #32, I am closing this bug.

Changed in xulrunner:
status: In Progress → Fix Released
Changed in xulrunner:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.