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)
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)
Severity: normal → critical
Component: General → Security
QA Contact: general → thunderbird
Summary: Cannot initialize brosers security component on NT → Cannot initialize browsers security component on NT
Comment 1•15 years ago
|
||
did we broke NT support in latest NSS ?
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
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!
Updated•15 years ago
|
Whiteboard: [workaround comment 4] [support]
(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.
Comment 5•15 years ago
|
||
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 )
Comment 6•15 years ago
|
||
(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
Comment 7•15 years ago
|
||
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.
Comment 8•15 years ago
|
||
I guess there's no point in resurrecting this now.
Flags: blocking1.8.1.next? → blocking1.8.1.next-
Comment 9•15 years ago
|
||
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.
Comment 10•14 years ago
|
||
(In reply to comment #9) > I'm seeing this with Shredder 3.2a1pre on Windows XP with FIPS enabled... That was bug 521849
Comment 11•14 years ago
|
||
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
Comment 12•13 years ago
|
||
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.
Description
•