Bug 201922 - firefox- fails SSL
firefox- fails SSL
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kai Engert (:kaie)
: 202017 214858 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-08-09 15:42 EDT by nezihkartal
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version: nss-3.11.1-1.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-11 01:02:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot about the error (39.27 KB, image/png)
2006-08-09 15:42 EDT, nezihkartal
no flags Details
Change Master Password (27.97 KB, image/png)
2006-08-10 16:38 EDT, nezihkartal
no flags Details

  None (edit)
Description nezihkartal 2006-08-09 15:42:36 EDT
Description of problem:
i upgraded my Firefox, from to i can't connect to secure sites
(email services, online banking etc...) with firefox it says "Firefox
doesnt know how to communicate with the server". i tried to remove
/home/user/.mozilla folder, but it didnt work. i couldnt even connect here
(redhat's bugzilla) to report this error... if i downgrade to, all of
that sites, work again.

Version-Release number of selected component (if applicable):

How reproducible:
install or upgrade to firefox

Steps to Reproduce:
1.go to www.gmail.com or mail.yahoo.com or www.hotmail.com
Actual results:

Expected results:

Additional info:
there are two input boxes for "current password" in "set master password".
Comment 1 nezihkartal 2006-08-09 15:42:37 EDT
Created attachment 133878 [details]
screenshot about the error
Comment 2 Christopher Aillon 2006-08-10 01:03:59 EDT
Comment 3 Kai Engert (:kaie) 2006-08-10 13:56:07 EDT
I can not reproduce this bug.

On my i686 machine running latest FC5, using firefox- I can access
any secure site just fine. I tried both my old profiles and a clean environment
(fresh .mozilla).

Something is wrong on your machine, but what?

I assume your system is up to date, you probably used a general "yum update"

What versions of packages nspr and nss are installed on your machine?
Comment 4 Kai Engert (:kaie) 2006-08-10 13:57:34 EDT
(In reply to comment #0)
> Additional info:
> there are two input boxes for "current password" in "set master password".

This sounds very confusing. Where do you get this weird dialog? Could you please
attach a screenshot?
Comment 5 Warren Togami 2006-08-10 16:00:52 EDT
*** Bug 202017 has been marked as a duplicate of this bug. ***
Comment 6 nezihkartal 2006-08-10 16:38:47 EDT
Created attachment 133987 [details]
Change Master Password
Comment 7 nezihkartal 2006-08-10 16:40:29 EDT
nspr and nss versions are;
Comment 8 Kai Engert (:kaie) 2006-08-10 18:39:22 EDT
(In reply to comment #7)
> nss-3.11-4

That's the cause!
I downgraded to that release, and immediately saw the same errors as you get.
Both the "ssl broken" and the "additional field in master password dialog".

As a quick woraround, can you please try a "yum update firefox nss" on your
system? I hope this will work for you.

This tells me, every time we update the mozilla application packages, we should
add a "requires" line to the spec file, where we require the latest nss version
we have released on the system. The latest nss version release on the system
will be used when building mozilla apps. And it seems, this might introduce
dependencies on that newer release.
Comment 9 Kai Engert (:kaie) 2006-08-10 18:43:58 EDT
This bug only occurs, when people explicitly update selected packages only.

I think, you wouldn't have seen this bug, when you had installed all available
update packages.

Chris: Does this bug justify to push out new firefox etc. packages with an
appropriate "requires"?
Comment 10 Christopher Aillon 2006-08-10 19:21:32 EDT
It will be a maintenance nightmare to have to do this.  This is exactly what
I've fought so hard over the past few years to break away from.  We shouldn't
have to keep changing Requires.  I think the nss soname should have changed in
this case if it is no longer compatible.
Comment 11 Carsten Clasohm 2006-08-13 12:38:42 EDT
I had the same problem on a FC5 machine where only firefox but not nss had been
updated. Once the user has run firefox with the old nss package, a later
upgrade of the nss package will not fix this problem.

You also have to delete ~/.mozilla/firefox/*/compreg.dat. It will be recreated
when Firefox is started. The problem also manifests itself when you look at Edit
- Preferences - Advanced - Security - Security Devices. The Security Devices and
Modules list will be empty.

To reproduce, run

root> rpm -e --nodeps nss firefox
root> rpm -i nss-3.11-4.i386.rpm firefox-

user> mv ~/.mozilla ~/.mozilla.bak
user> firefox
[no SSL support]

root> rpm -U nss-3.11.1-1.fc5.i386.rpm firefox-

user> firefox
[still no SSL]
user> rm .mozilla/firefox/*/compreg.dat
user> firefox
[now SSL works]
user> rm -rf .mozilla
user> mv .mozilla.bak .mozilla
Comment 12 Carsten Clasohm 2006-08-13 12:41:37 EDT
BTW, this also applies to thunderbird-
Comment 13 Kai Engert (:kaie) 2006-08-15 18:39:32 EDT
The reason why it does not work:
with old NSS and new Firefox installed, we have this situation:

user> ldd /usr/lib/firefox-
/usr/lib/firefox- /usr/lib/libnss3.so: version
`NSS_3.11.1' not found (required by

(In reply to comment #11)
> Once the user has run firefox with the old nss package, a later
> upgrade of the nss package will not fix this problem.

Yes, this is true. The compreg.dat file only gets updated when the firefox
package gets updated. I believe, once we agree on a fix, releasing an updated
firefox package will fix broken installations. I looked at what's happening when
updating from ff to ff and starting ff after that. The
compreg.dat in the profile directory got recreated (newer timestamp).

Using your test case I did NOT get the broken behaviour.

> root> rpm -e --nodeps nss firefox
> root> rpm -i nss-3.11-4.i386.rpm firefox-
> user> mv ~/.mozilla ~/.mozilla.bak
> user> firefox
> [no SSL support]

In this combination SSL works fine for me.

> root> rpm -U nss-3.11.1-1.fc5.i386.rpm firefox-
> user> firefox
> [still no SSL]

This also works fine for me.

But in order to reproduce the problem you describe one can do do this:

root> rpm -e --nodeps nss firefox
root> rpm -i nss-3.11-4.i386.rpm firefox-
user> rm .mozilla/firefox/*/compreg.dat
user> firefox

[no ssl]

root> rpm -U nss-3.11.1-1.fc5.i386.rpm

[still no ssl, although newest packages installed]

So yes, with out current released packages, users who ended up with such a
broken build are not able to fix it by just updating all packages to current

They either have to remove compreg.dat files,


their compreg.dat files will get fixed automatically when we push a new firefox

But in order to really make this work, we need to manually tweak the NSS version
required by the firefox package, as specified in the firefox.spec file. We need
to set that version to 3.11.1.

While the above is sufficient, IMHO, to fix the current issue, we need to decide
what should happen in the future.

The same bug could be re-introduced any team where:

- firefox x.1 gets pushed

- nss gets updated to a newer release that has additional public symbols, and
somehow the NSS code itself requires such an additional public symbol (this is
what happened this time, culprit was newly exported function

- firefox x.2 gets pushed, or even just rebuilt

In that firefox rebuild step, the build process will find the most recent NSS
headers and make firefox dependent on that newer NSS release.

In my unerstanding, the only ways to prevent the problem are:

Option A) either MANUALLY tweak the requires line contained in firefox.spec to
specify the NSS release of the latest released RPM package

Option B) find a way to do the above automatically. Query the system for the
installed NSS release, and read that into a variable <required-nss-release> and
make the Requires line use that:
  Requires nss >= %{required-nss-release}

option C) Each time we release an updated NSS release that introduces new
symbols, use a different name for the shared libraries, requiring all dependent
apps to be rebuilt

My personal preference would be option B)
Is that possible to do?

(Chris, we really would like to avoid to go back to a world where NSS is shipped
multiple times with each application)
Comment 14 nezihkartal 2006-08-16 16:07:50 EDT
(In reply to comment #12)
> BTW, this also applies to thunderbird-

i agree. getting mail function broken down after upgraded to i removed
.thunderbird/*/compreg.dat, it became to able to get e-mails, again ;) thanks to
Kai Engert, Carsten Clasohm, and other helpers...
Comment 15 Christopher Aillon 2006-11-09 15:22:03 EST
*** Bug 214858 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.