Closed Bug 512043 Opened 15 years ago Closed 13 years ago

Cannot initialize browsers security component on NT because it links against SHGetSpecialFolderPathW

Categories

(Thunderbird :: Security, defect)

x86
Windows NT
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jhanks, Unassigned)

References

Details

(Keywords: qawanted, regression, Whiteboard: [workaround comment 4] [support])

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; T312461)
Build Identifier: 2.0.0.23 (20090812)

I updated from 2.0.0.22 to 2.0.0.23 today on two different NT systems.  When I launch Thunderbird, I get he mesage 'Could not initialize browser's security component...'  

There were many suggestions on the web to check if the disk was full, check permissions on the directory, etc. from June.  None of these helped and the odds of two separate machines failing in the same way (in diferent locations) is a bit much to beleive anyway.

There was one other user on mozillaZine who reported the same probelm and the
suggestion was to make a bug report (I cold not find that he did so I am).

One suggestion was to delete the cert8.db file which would automtically be recreated the next time Thundersbird started.  I did this and I still got the same error and the file was not recreated.

This lease me to wonder if 2.0.0.23 no longer knows how to find the profile on NT.

I could find no reference specfically for NT, only 98, ME, 2000 or XP.  one of the sites suggested finding your profile by entering 
'%APPDATA%\Mozilla\Firefox\Profiles\' to the Start->run box.  

Whe I do this I get the error 'Cannot find the file...' If Thunderbird is now using this name to find the profiles, that may explain why it can no longer find the profile directory to read or write the file.

Reproducible: Always

Steps to Reproduce:
1.Start Thunderbird
2.
3.
Actual Results:  
I got the error message

Expected Results:  
Thunderbird to start and run. 

I;m not sure how to classify it.  If you are using NT, it is a major bug. If not, it's trivial. reloading 2.0.0.22 may solve the problem so that may be an easy work around (as longs as I remember not to do any updates)
Component: General → Security
QA Contact: general → thunderbird
Summary: Cannot initialize brosers security component on NT → Cannot initialize browsers security component on NT
did we broke NT support in latest NSS ?
Windows NT 4.0 is no longer a "Tier 1" platform.  That means that ensuring
that NSS works on it is no longer something we test before making a release.
We decommitted support for it at the same time as Win 9x and Win ME.

In this latest release, I think we did not intentionally or knowingly break 
support for Win NT 4.0, but if it is broken, we are not likely to fix it.  

It would be interesting to know why it is not working, but the NSS team will 
not be setting up an NT 4.0 box to find out why.
I found a workaround (more of a hack-around).  I haven't tried my production profile with it yet, but I think it will show your engineers where the problem is. 

The DLL "freebl3.dll" (version 3.12.3.1) requires an import:
SHELL32.dll
     55   SHGetSpecialFolderPathW

This API only exists on NT4 when "Active Desktop" or something is installed.

My hack-around:
1.  modify "freebl3.dll" to import from "ADSHL32.DLL" instead of "SHELL32.DLL"
2.  retrieve a copy of the "Active Desktop" SHELL32.DLL from Microsoft KB841356 (the file is named "ADSHELL32.DLL")
3.  rename it to "ADSHL32.DLL" and also change its export name to the same
4.  copy it to the directory containing "Thunderbird.exe" and "freebl3.dll"

Lastly, if you are going to officially drop support for Windows NT, you should  announce it in the Release Notes and stop the auto-update system to suggest it to installations on Windows NT.  I think this is how it was done beginning with Firefox 3.0.

I also wish that this information would allow you to continue to make Thunderbird 2, or even Firefox 3, work on NT.

Thanks!
Whiteboard: [workaround comment 4] [support]
Blocks: 512180
(In reply to comment #0)
> I updated from 2.0.0.22 to 2.0.0.23 today on two different NT systems.  When I
> launch Thunderbird, I get he mesage 'Could not initialize browser's security
> component...'  

I'm seeing this as well on NT 4.0.

I thought this might be an ignorable warning, but it does disable SSL and HTTPS, which seems to be commonly used for embedded images in advertisements, and of course any secure IMAP/POP3 connections.


> One suggestion was to delete the cert8.db file which would automtically be
> recreated the next time Thundersbird started.  I did this and I still got the
> same error and the file was not recreated.

Likewise. No cert8.db file created.

Other suggestions listed here:
http://kb.mozillazine.org/Could_not_initialize_the_browser_security_component
don't apply or don't help.


> This lease me to wonder if 2.0.0.23 no longer knows how to find the profile on
> NT.

Seems unlikely, as other functionality that depends on the profile folder still works. More likely to be caused by a missing DLL function, as the other poster suggests.


(In reply to comment #3)
> ...if you are going to officially drop support for Windows NT, you should 
> announce it in the Release Notes and stop the auto-update system to suggest it
> to installations on Windows NT.

I second that.
Just thought I would mention this appears to be the same thing that is causing problems on SeaMonkey 1.1.18 under 95/NT ( Bug 514955 )
Blocks: 514955
(In reply to comment #2)
> Windows NT 4.0 is no longer a "Tier 1" platform.

For NSS. unfortunately it is supposed to be a supported platform for Thunderbird 2.

> We decommitted support for it at the same time as Win 9x and Win ME.

Those are also supported platforms for Thunderbird 2.
http://www.mozilla.com/en-US/thunderbird/system-requirements.html

Man, these drop-in, "binary compatible" new versions don't simply drop-in nor are entirely compatible. Sigh.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.next?
Keywords: qawanted, regression
They are on the supported platforms.  I honestly thought that support for 
Win9x and NT 4 had been dropped YEARS ago.  This problem can obviously be
overcome, but not in the same source tree that is FIPS certified.
I guess there's no point in resurrecting this now.
Flags: blocking1.8.1.next? → blocking1.8.1.next-
I'm seeing this with Shredder 3.2a1pre on Windows XP with FIPS enabled. When started, Shredder displays the error message, master password appears not to be set and FIPS is disabled.
(In reply to comment #9)
> I'm seeing this with Shredder 3.2a1pre on Windows XP with FIPS enabled...
That was bug 521849
I developed a binary patch for Thunderbird 2.0.0.24, which works on a standard Windows NT4 installation, without the need for the Active Desktop shell32.dll in Edwin Kwan's workaround above. As Edwin Kwan pointed out, the problem is caused by the call to SHGetSpecialFolderPathW in freebl3.dll (win_rand.c). This function doesn't exist in the shell32.dll of a standard NT4 installation. However, there is a very similar function SHGetFolderPathW in the shfolder.dll which is available on a standard NT4 installation (and which Microsoft designates as superset of SHGetSpecialFolderPath). Therefore my idea was to divert the call from SHGetSpecialFolderPathW to SHGetFolderPathW. Unfortunately SHGetFolderPathW has a somewhat different parameter structure than SHGetSpecialFolderPathW, especially it needs one parameter more. The original call to SHGetSpecialFolderPathW in freebl3.dll looks like this on a binary level:

001439 8b10            mov     edx,dword ptr [eax]
00143b 6a00            push    0                   ; fCreate
00143d 8d442410        lea     eax,[esp+10h]
001441 52              push    edx                 ; nFolder
001442 50              push    eax                 ; pszPath
001443 6a00            push    0                   ; hwndOwner
001445 ffd7            call    edi                 ; SHGetSpecialFolderPathW

Luckily, there exists an opcode sequence which generates the required parameter structure for SHGetFolderPathW, including the additional parameter, and still fits in the available 12 bytes:

001439 8d54240c        lea     edx,[esp+0Ch]
00143d 52              push    edx                 ; pszPath
00143e 31d2            xor     edx,edx
001440 52              push    edx                 ; dwFlags
001441 52              push    edx                 ; hToken
001442 ff30            push    dword ptr [eax]     ; nFolder
001444 52              push    edx                 ; hwndOwner
001445 ffd7            call    edi                 ; SHGetFolderPathW

After this, the import table must be patched to divert the call to shfolder.dll -> SHGetFolderPathW.

Original (The "55 00" at the beginning is the DLL import hint):

038D60 XX XX XX XX XX XX XX XX XX XX 55 00 53 48 47 65           U.SHGe
038D70 74 53 70 65 63 69 61 6C 46 6F 6C 64 65 72 50 61 tSpecialFolderPa
038D80 74 68 57 00 53 48 45 4C 4C 33 32 2E 64 6C 6C 00 thW.SHELL32.dll.

Patched:

038D60 XX XX XX XX XX XX XX XX XX XX 01 00 53 48 47 65           ..SHGe
038D70 74 46 6F 6C 64 65 72 50 61 74 68 57 00 00 00 00 tFolderPathW....
038D80 00 00 00 73 68 66 6F 6C 64 65 72 2E 64 6C 6C 00 ...shfolder.dll.

Finally, the import table pointer to the shfolder.dll entry must be adjusted.

Original:

038A28 84 8D 03 ; -> SHELL32.dll

Patched:

038A28 83 8D 03 ; -> shfolder.dll

This patch restores the full functionality of Thunderbird 2.0.0.24 under Windows NT4, however with one sideeffect: Since the binary patch breaks the signature of freebl3.dll in freebl3.chk, FIPS mode can't be switched on. Those who don't know what FIPS mode is probably don't need it, and don't need to take any further action. Those who do need FIPS mode (or perfectionists ;-) can fix this by generating a new freebl3.chk with shlibsign.exe.
Summary: Cannot initialize browsers security component on NT → Cannot initialize browsers security component on NT because it links against SHGetSpecialFolderPathW
Thunderbird 2.0.0.x is no longer supported, therefore closing this as wontfix.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.