Bug 456189

just in case this isn't clear: the new seamonkey/nss packages work as expected
as long as the URL is not launched from thunderbird.

Actually, can reproduce even with seamonkey-1.0.9-20.el4

The last RHEL 4 seamonkey package that used an internal nspr/nss, rather than
our new system package, was version 1.0.9-16.el4

It would be interesting to test the behavior of  versions
  seamonkey-1.0.9-16.el4
and
  seamonkey-1.0.9-17.el4

If 1.0.9-16.el4 works correctly, then this regression was introduced as part of
the migration to nspr/nss system packages.

I can always reproduce this bug, it's not necessary to open the URL from
thunderbird. I simply open any https:// URL in seamonkey and get the error.

I think you had enabled FIPS mode in your browser profile, can you confirm?

I think in the past it was not possible to enable FIPS in RHEL 4 in the browser.
I just tried with old seamonkey-nss-1.0.9-16.el4.i386.rpm (from before our
switch to system nss), and I am unable to switch to FIPS mode, the seamonkey
error console gives me a failure message.

I think the reason why that didn't work in the past, we probably had a bug that
caused us to install .chk files that didn't match the installed .so files.

Now with our newer nss packages we make sure that we install matching files, and
enabling FIPS mode works.

But, unfortunately, we don't have a prelink protection in RHEL 4 :-/
I mean, prelink modifies the .so, the .chk file no longer matches the .so, and
FIPS mode fails.


I think:
- you enabled FIPS mode while the files matches
- cron started prelink
- mismatch and failure


Using our recent seamonkey packages, try to use
  mozilla -ProfileManager
and create a new profile (which has FIPS mode disabled by default).
Then open the https:// link using that profile, and it should work.

Enabling FIPS mode should fail, because we have the mismatch.


You can manually downgrade to the older packages, and then (again) update to our
recent packages. This will temporarily fix your profile that has FIPS enabled.

Run prelink (e.g. manually run /etc/cron.daily/prelink) and it will be broken again.


Unfortunately you can't disable FIPS mode while having mismatching files on your
system, because NSS won't start up in the FIPS mode that's recoded in file secmod.db

A workaround should be: Find your application profile directory
(~/.mozilla/default/...../) and delete file secmod.db - You'll have to
re-install/register any 3rd party crypto modules in that profile (which most
people probably don't do anyway)


Another test you can do to prove my theory (I did this already):
- downgrade to old seamonkey packages including seamonkey-nss
- again install the newer ones
(Now you have matching files, it should take a while until prelink gets started)
- try your original profile (which has FIPS enabled) and now it'll work
- it will be broken again as soon as prelink runs

Now you'll ask, what is the right fix to this problem?

We'd have to do something we already did in RHEL 5, which requires an update to
the "prelink" package, and another update to nss, in order to ensure that we get
updated nss files that will then be protected.

The change to prelink is minimal, at the configuration file level:
We must add 2 lines to file /etc/prelink.conf :
-b /lib{,64}/libfreebl3.so
-b /lib{,64}/libsoftokn3.so

The current version of prelink is: prelink-0.3.3-0.EL4

We must produce a prelink package with an updated version-release number, and
our updated NSS package will have to use this additional statement in the
nss.spec file:

# Only compatible with prelink when using a prelink.conf that has NSS signed
# libraries blacklisted
Conflicts: prelink <= prelink-0.3.3-0.EL4


See also bug 237350 and bug 230546

I can work on this, if you give me the approval flags.

Setting rhel‑4.7.z to '?' as its a critical bug fix.

Changing component to "prelink", as that is where the fix will be added (blacklist).

I'm keeping myself as bug owner, I'm happy to do this change, but I'd like to
wait for an OK from Jakub.

(In reply to comment #4)
> I can always reproduce this bug, it's not necessary to open the URL from
> thunderbird. I simply open any https:// URL in seamonkey and get the error.

Interesting. I could only reproduce from thunderbird. I'll try again.
Note that my testing was done with a new profile.  I'll try again to confirm.
 
> I think you had enabled FIPS mode in your browser profile, can you confirm?

I did not change any of the default settings.

Raising priority, because affected users are unable to use the browser to
connect to secure web sites.

I had been able to reproduce Ben's problem when enabling FIPS mode.

I was never able to reproduce with FIPS mode disabled (the default).

But Ben told me he did not use FIPS mode.

This means:
- what I have described in the most recent comments might be a different issue
- I do not yet understand what causes the problem that Ben has originally reported.

Ben now gave me access to a test system, and I was able to reproduce it there.
I will have to try harder to reproduce it locally, or will have to debug on the
test system...

The bug I have found and described is separate from what Benl had reported
initially. Let's keep this bug for the new FIPS related issue.

Benl has filed his bug again, bug 456619, and we now understand that problem, too.

Created attachment 316265 [details]
Patch for prelink in RHEL 4

Created attachment 316266 [details]
Patch for nss in RHEL 4

Fixed as bug #495936.