Description of problem: i upgraded my Firefox, from 1.5.0.4 to 1.5.0.6. i can't connect to secure sites (email services, online banking etc...) with firefox 1.5.0.6. 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 1.5.0.4, all of that sites, work again. Version-Release number of selected component (if applicable): firefox-1.5.0.6-2.fc5 How reproducible: install or upgrade to firefox 1.5.0.6 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".
Created attachment 133878 [details] screenshot about the error
Kai?
I can not reproduce this bug. On my i686 machine running latest FC5, using firefox-1.5.0.6-2.fc5 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" already. What versions of packages nspr and nss are installed on your machine?
(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?
*** Bug 202017 has been marked as a duplicate of this bug. ***
Created attachment 133987 [details] Change Master Password
nspr and nss versions are; nspr-4.6.1-2.2 nss-3.11-4
(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.
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"?
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.
I had the same problem on a FC5 machine where only firefox but not nss had been updated. Once the user has run firefox 1.5.0.6 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-1.5.0.4-1.2.fc5.i386.rpm user> mv ~/.mozilla ~/.mozilla.bak user> firefox [no SSL support] root> rpm -U nss-3.11.1-1.fc5.i386.rpm firefox-1.5.0.6-2.fc5.i386.rpm 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
BTW, this also applies to thunderbird-1.5.0.5-1.1.fc5
The reason why it does not work: with old NSS and new Firefox installed, we have this situation: user> ldd /usr/lib/firefox-1.5.0.6/components/libpipnss.so /usr/lib/firefox-1.5.0.6/components/libpipnss.so: /usr/lib/libnss3.so: version `NSS_3.11.1' not found (required by /usr/lib/firefox-1.5.0.6/components/libpipnss.so) (In reply to comment #11) > Once the user has run firefox 1.5.0.6 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 1.5.0.4 to ff 1.5.0.6 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-1.5.0.4-1.2.fc5.i386.rpm > > 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-1.5.0.6-2.fc5.i386.rpm > > 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-1.5.0.6-2.fc5.i386.rpm 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 releases. They either have to remove compreg.dat files, or, their compreg.dat files will get fixed automatically when we push a new firefox release. 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 SEC_ASN1EncodeUnsignedInteger) - 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)
(In reply to comment #12) > BTW, this also applies to thunderbird-1.5.0.5-1.1.fc5 > i agree. getting mail function broken down after upgraded to 1.5.0.5. i removed .thunderbird/*/compreg.dat, it became to able to get e-mails, again ;) thanks to Kai Engert, Carsten Clasohm, and other helpers...
*** Bug 214858 has been marked as a duplicate of this bug. ***