Closed Bug 58417 Opened 24 years ago Closed 23 years ago

Unable to Encrypt Sensitive Info.

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: skasinathan, Assigned: javi)

References

Details

(Keywords: hang, platform-parity, regression, Whiteboard: [rtm-] relnote-user) 

Steps:
1. One on the mail basic functionality test is to encrypt the stored mail 
passwords. Goto Tasks | Privacy and Security | Password Manager | Encrypt 
Sensitive info. After you select this, no window pops up. It FREEZES the 
browser. 

Platform and build:
2000-10-28-09-MN6 on Linux and Mac. Hoping the same on Windows (no windows build 
to test).

PS: Please change the component, if you think so.
nominating for rtm.
Keywords: regression, rtm
COnsole window displays the foll.

Document http://home.netscape.com/ loaded successfully
we don't handle eBorderStyle_close yet... please fix me
Setting content window
*** Pulling out the charset
in SetSecurityButton

I just tried this on a windows mozilla branch build and it works-for-me.  Will 
try it on a windows commercial branch build in a few moments (after my build 
finishes).

I started with a fresh profile which means that there was no data to encrypt.  
That is what the above steps implied.
I just tried it on a commercial branch build and again it works-for-me.  I also 
tried it after first saving some single-signon data.  In that case I got the 
dialog asking me to create a master password (no such dialog appears when there 
is no data to encyrpt).

Morse, I tried again using the same Linux branch commercial build
(2000-10-28-09-MN6). I tried couple of ways.

I. a) Created a new profile. Created a new IMAP account and checked save
password in the password dialog.
   b) I quit the app, launch again using the same profile. Tried to encrypt the
saved password.  NO, it doesn't bring up the master password (Private key)
dialog.  I should get this dialog, right?  and it freezes the browser.

II. a) Same steps as above, but didn't quit the app in step b.

The only difference I see is that you tried on Windows and I tried on Linux and
Mac! 
suresh, could you try this on windows and see what you get?
Morse, YES! It works fine on Windows. I can see the Master PAssword dialog.
Builds tested: 2000102916MN6 windows branch commercial build on Win NT 4.0.
SingleSignon, I think. Please reassign if I'm wrong.
Assignee: mstoltz → morse
Component: Security: General → Single Signon
QA Contact: czhang → tpreston
Sounds like this is WORKSFORME.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Mitchell Stoltz, This DOESN'T workforme. I said it works fine only in Windows.
It doesn't work on linux and Mac.
Status: RESOLVED → REOPENED
Component: Single Signon → Security: General
QA Contact: tpreston → czhang
Resolution: WORKSFORME → ---
It is waaaaay to late to be finding this. It's marked "regression" -- when was
the last time it worked? Maybe we can find the guilty check-in.

Suresh: how did you install the Mac and Linux builds. If you use the tarballs
instead of the the installers it is possible you did not get PSM. Do secure
sites work for you? Even if no PSM you shouldn't hang, of course.
Whiteboard: [rtm need info]
dveditz, I marked this as "regression" because I know for sure that this use to
work before. It was working on 10/16 Linux build (Not sure about mac, but I do
know that Mac brings up an empty dialog before. bug 57081).

I did a Full Install(using the installer) on linux. I downloaded the tarball
(netscape*.sea.bin) on Mac.

Yes, PSM works fine on both Mac and Linux.
*** Bug 57081 has been marked as a duplicate of this bug. ***
Just to reiterate, This problem occurs only on Linux and Mac. It works fine on
Windows.

Morse, did you get a chance to look at this problem on Linux/Mac? Thanks!
I'm confused by Suresh's comment on on 10/30 about bug 57081.  I believe that
bug was fixed on Friday the 27th.  Can you verify what the problem is on the mac
here?

I'm copying Pavlov to try to get additional input on the Linux situation for
this bug ('cause he hates when Linux lags behind windows!)

Can we have an update for the two platforms (Mac and Linux)?
OK, I'm able to reproduce this on linux.  And I agree -- this is quite 
serious.  When did this regression start?

We are hung inside of cartman.  Here's a stack trace at the time of the hang:

#0  0x4038258b in __sigsuspend (set=0xbefffbe4)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x402d1211 in __pthread_lock (lock=0x83fbf94, self=0xbefffe60)
    at restart.h:32
#2  0x402ce99a in __pthread_mutex_lock (mutex=0x83fbf84) at mutex.c:84
#3  0x402ababb in PR_Lock (lock=0x83fbf84) at ptsynch.c:167
#4  0x402ac8ac in PR_EnterMonitor (mon=0x83fbf80) at ptsynch.c:492
#5  0x4224c93b in nsPSMMutexLock (p=0x4227ce18) at nsPSMMutex.c:56
#6  0x41df2b76 in CMT_ProcessEvent (cm_control=0x84f1638) at cmtevent.c:232
#7  0x41df2c59 in CMT_EventLoop (cm_control=0x84f1638) at cmtevent.c:262
#8  0x42251801 in CARTMAN_UIEventLoop (data=0x84f1638)
    at nsPSMUICallbacks.cpp:206
#9  0x402b39fb in _pt_root (arg=0x84f1810) at ptthread.c:198
#10 0x402cdeca in pthread_start_thread (arg=0xbefffe60) at manager.c:213
Assignee: morse → ddrinan
Status: REOPENED → NEW
Thanks Morse for looking into the problem!!

Jar, let me clear your confusion. The bug 57081 is a Mac only bug. It was
reported using 10/16 build. Using this build on Mac when you launch Single
signon window, the window is EMPTY. There was nothing inside the window. Javi
attached a patch to that bug, but I'm not sure whether it was checked into the
tree. Looking at the bug activity  junruh@netscape.com marked that bug as fixed
and verified. Yesterday I reopened that bug coz we are still seeing the problem
on Mac and Linux (Note that Mac doen't even brings up the empty window).
I marked bug 57081 as a dup of this one as per discussion with Lisa and Esther
yesterday! Hope this clears things up!
Adding nitinp to the cc-list.
QA > junruh
Component: Security: General → Security: Crypto
QA Contact: czhang → junruh
I am able to reproduce it with the 20001030 branch build of linux. It was 
working before , must have crept in sometime. Today's build are useless so will 
try to  reproduce the bug tomorrow or whenever a working build is available
so in the morning I thought I will try and trace the beginning of this supposed
bug. I could find only 2000-10-26-09-MN6 as the earliest branch build. I
installed that build on linux. The encript sensitive data works fine. I tried
all combinations possible.
Changed edit|preferences , Obscured data and then encrypted data.
Then I jumped onto the 2000-10-30-09-MN6. In fact I deleted the dirs in .mozilla
to start over again. So I migrated the nova profile again and setup new db
password and everything works fine. I haven't tested on the 2000-10-31 builds
since they had some test stopper bugs in them. I will try again with today's
branch builds.
But in short it WORKSFORME.
nitinp, I didn't understand your previous two comments.

Your comment on 2000-10-31 16:20 says "I am able to reproduce it with the
20001030 branch build of linux."

Your comment on 2000-11-01 09:11 says "Then I jumped onto the 2000-10-30-09-MN6.
In fact I deleted the dirs in .mozilla
to start over again. So I migrated the nova profile again and setup new db
password and everything works fine."

Does the builds you are referring in the above comments refer to the same build?
If yes, you are saying that you were able to reproduce yesterday but not today.
right?
Am I missing something here? Thanks!!




I did reproduce it for the 20001030 branch build. But that was with an old
profile. But then today I removed all the files in .mozilla and restarted
netscape6 which migrated my nova profile and since then I cannot reproduce the
bug. In fact I just installed the 2000-10-31-14-MN6 and tried to reproduce the
bug , but cannot reproduce it.


Based on preceding comment, I deleted all my old profiles and removed everything 
from the .mozilla directory.  Then tried this test again and I am still able to 
reproduce the problem.
which build are you testing?
Using the latest MN6 builds from 10/31.
Still reproducible on Mac and linux. Win98 and WinNT is OK.
Just create a new profile, enter your name and password at mail.yahoo.com, save 
it, then immediately encrypt the data.
To setup new profiles:
For Linux, type ./netscape -ProfileManager (./netscape -h for help)
For Mac, drag the file Netscape Profile Manager onto the Netscape 6 file.
Is a workaround acceptable?

My hunch is that if you got to
Tasks->Privacy and Security->Password Manager->Change Personal Security Password
and set the Personal Security Password first.  Then setting the option to
encrypt should "just work(TM)."
but does this happen only if the password is not set or it happens even if the
password is set.
The fact that a new profile is being created means you have a new db. But I
tested it after I set the password from the security advisor. I assumed that the
password is already set.
So suresh - when you created a new profile did activate SDR from the prefs
dialog? or you went to IMAP account ,clicked OK on the big box and tried to
encrypt it.
The bug then will be that the new password window does not come up and freezes
the browser when trying to encrypt sensitive data , because it works for a new
profile with a password set for the profile.
nitinp, I removed .mozilla, created a new profile, created a imap account and
while logging in I checked the box to remember password. Then tried to encrypt
the password. Hangs.

And also tried using 2000-11-01-09-MN6 build. Same result (Hangs).
without setting up the password the new profile does freeze up when I try to
encrypt a data I just saved. When I restart netscape6 with that profile and set
the password from the tasks|privacy and security|password manager|personal
security password it works fine after that.

....so any new updates on this bug? Thanks!
Here is a mac stack trace

 (CurStackBase does not seem to apply...dumping 4K.)
  Return addresses on the stack
  Stack Addr  Frame Addr   ISA   Caller
   09BEC3C4                PPC   00690070
   09BEC326                PPC   0068FFFC
   09BEC1EC                68K   0000000A
   09BEC014                PPC   00690070
   09BEBD5C                PPC   1AC2E010 PR_GetThreadPrivate+004F4
   09BEBCC6                68K   00D7FFFA
   09BEBCA6                68K   03280346
   09BEBBD8    09BEBBD0    PPC   1AC2FAA8 PRP_TryLock+00994
   09BEBB86                68K   09C5FFFE
   09BEBB78    09BEBB70    PPC   1AC2DFF4 PR_GetThreadPrivate+004D8
   09BEBB28    09BEBB20    PPC   1AC34644 PR_GetPrimaryThread+002A0
   09BEBB18    09BEBB10    PPC   1AC2E4A0 _PR_GetPrimordialCPU+0045C
   09BEBAE8                68K   FFD61FDA WaitNextEvent+0002A
   09BEBA68    09BEBA60    PPC   1AC3518C PR_LocalTimeParameters+0019C
   09BEBA34    09BEBA30    68K   0007189E
   09BEB9C8                PPC   0036F11C EmToNatEndMoveParams+00014
   09BEB978    09BEB970    PPC   001E79E4 MPSecondaryInitializeAPI+001EC
   09BEB93E                68K   092C092A
   09BEB938    09BEB930    PPC   001E97FC MPGetPoolStatistics+002A4
   09BEB928    09BEB920    PPC   00952A98
   09BEB850    09BEB84C    68K   002E119C 'scod BFAF 0002'+01EEC
   09BEB840    09BEB83C    68K   002E5566 'scod BFAF 0002'+062B6
   09BEB830    09BEB82C    68K   002F0D88 'scod BFAF 0002'+11AD8
   09BEB80C                68K   002F0E2C 'scod BFAF 0002'+11B7C
   09BEB808                PPC   0036F11C EmToNatEndMoveParams+00014
   09BEB7E8    09BEB7E4    68K   002E558E 'scod BFAF 0002'+062DE
   09BEB7C8    09BEB7C0    PPC   001E7A60 MPSecondaryInitializeAPI+00268
   09BEB7A0                68K   002F2B56 'scod BFAF 0002'+138A6
   09BEB790    09BEB78C    68K   FFC416A2 _LoadScrap+00E10
   09BEB788    09BEB780    PPC   001E97FC MPGetPoolStatistics+002A4
   09BEB778    09BEB770    PPC   00951684
   09BEB756                68K   038FFFFE
   09BEB750                68K   002E119C 'scod BFAF 0002'+01EEC
   09BEB6F8    09BEB6F0    PPC   1C8229B4 InitFloatingWindows+00A18
   09BEB6C8    09BEB6C0    PPC   1C822924 InitFloatingWindows+00988
   09BEB6A0                68K   002F2B56 'scod BFAF 0002'+138A6
   09BEB690    09BEB68C    68K   0077D2A6
   09BEB688                PPC   1C816998 DeactivateFloatingWindows+001C8
   09BEB650    09BEB64C    68K   005358D4
   09BEB63E    09BEB63A    68K   002E1220 'scod BFAF 0002'+01F70
   09BEB62E                68K   0042E29E
   09BEB618                68K   FFC41782 _LoadScrap+00EF0
   09BEB5E6    09BEB5E2    68K   002EA036 'scod BFAF 0002'+0AD86
   09BEB5BE    09BEB5BA    68K   002EA606 'scod BFAF 0002'+0B356
   09BEB580    09BEB57C    68K   002F0A8E 'scod BFAF 0002'+117DE
   09BEB56C    09BEB568    68K   002F097C 'scod BFAF 0002'+116CC
   09BEB54E                68K   002F0886 'scod BFAF 0002'+115D6
   09BEB54A                68K   00420960

I'm getting progressively more desperate... we really need some traction on this
from the Mac or Unix folks.

On the Mac, the best helpers should probably be Gordon or Patrick.

I'm not sure who on Unix should step forward... but I see no progress, and this
may either be a ship stopper, or a major problem at a minimum.

It appears there is a deadlock on the two platforms.  That may be a hint that we
are calling into PSM twice, and each call is trying to hold some locks (but I am
guessing with no basis in fact, never having looked at the code :-(  ).

Steve: Do you understand the general area of the code enough to *assure* that we
aren't making two parallel calls into PSM?
I suspect that this is yet another occurance of the SDR/PSM/UI deadlock that we
keep seeing and fixing.  Let me try to explain the sequence of events that occurs:

1. The password manager code calls the SDR encrypt function in the psm-glue
layer.  This is a synchronous call, it doesn't return until the encrypted data
is created (or an error occurs).
2. The psm-glue sends the request to PSM.  It then waits for the response.  The
response can be delivered as the first return packet, or there can be one or
more packets that are *events* that need to be handled.
3. PSM processes the encryption request.  In the problem case, it discovers that
a password needs to be set on the key database before progress can be made.  It
sends a UI request back to the application (psm-glue).  It then waits for the
response;
4. The code in psm-glue reads the UI request.  Here there may be some variation:
either the original request thread (Mozilla thread?) or a special event thread
may pick up the response.  I don't think it matters.  The handling thread calls
various Mozilla APIs to find a window, create a new window and feed it a URL to
use for fetching the data to display.  Buttons on the new UI window cause the
result to be sent back to PSM and the whole thing unwinds (if it's working!)

The problem:  apparently displaying the new UI usually depends on the Mozilla
(main?) thread being able to process operations.  However in this case it is
blocked in the psm-glue component waiting for a response from the SDR encrypt.
The result is typically an empty frame w/ NO content (this is for Windows).

Solution:The way we fixed this (several times) is to make the new UI window
"modal".  This seems to be a way to force the current thread to do event
processing, and allows the contents of the window to be displayed correctly.
This solution has been removed occasionally by people who didn't understand the
sensitivity of this code path.

I discussed this solution with several people back in May 2000.  I was worried
at that time that it seemed to be a "kludge", but I got general agreement that
it would work, and it does solve the problem.  In the future, we need to outline
a better architecture for this sort of flow (it apply to more than just PSM)

There's the info: it may be that modal handling on Linux and Mac does not work
any more, or something else could be wrong :)
To understand better what is happening, I instrumented the win32 build to see 
when the locks are getting set and unset.  Here are the locks that I observed, 
starting from the time that the tasks->privacy->password-manager->encrypt menu 
item is selected:

1. LOCK called from:

   CMT_SendMessage
   CMT_Hello
   nsPSMComponent::GetControlConnection
   nsSecretDecoderRing::Logout
   wallet_ReencryptAll
   ...

2. UNLOCK for 1 above

3. LOCK called from:

   CMT_SendMessage
   CMT_PassAllPrefs
   nsPSMComponent::PassPrefs
   nsPSMComponent::GetControlConnection
   nsSecretDecoderRing::Logout
   wallet_ReencryptAll
   ...

4. LOCK called from:

   CMT_ReferenceControlConnection
   CMT_EventLoop
   CARTMAN_UIEventLoop
   _PR_NativeRunThread
   _threadstartex
   KERNEL32! 77f04f3e()

5. UNLOCK for 3 above

6. LOCK called for:

   CMT_SendMessage
   CMT_LogoutAllTokens
   nsSecretDecoderRing::Logout
   wallet_ReencryptAll
   ...

7. UNLOCK for 6 above

8. LOCK called for:

   CMT_SendMessage
   tmp_SendMessage
   CMT_SDREncrypt
   nsSecretDecoderRing::Encrypt
   nsSecretDecoderRing::EncryptString
   EncryptString
   Wallet_Encrypt
   ...

and then the PSM screen for entering the "Personal Security Password" appears.

Now comparing this to the stack trace that I reported earlier for linux, it's 
clear that the hang is occuring at step 4 -- in the cartman UI event loop.  At 
this time the lock has been set from cartman's PassAllPrefs (step 3) and not yet 
released (it will be released in step 5).  The fact that the lock is already set 
doesn't bother windows but it does block linux.

Had a mid-air collision with thayes' comment above.  I think we are saying the 
same thing but I'm not sure.
Terry, please attach the solution that you referred (or cite a reference to it) 
so I can try it out and see if it solves the current problem.
The linux psm is no longer modal.We removed the modal behavior for PR3 because
there was a bug which hd rendered the Security Advisor useless. Making it
non-modal solved the problem. In fact we were sceptic that this may create
problems for SDR. Looks like it did.
john- is the mac psm modal to netscape6 ?
Nope. I can close the main window, and leave PSM still running.
So, what patch must be applied to make the dialog modal again on Mac & Linux?


Since window modality is being brought into this fray... I'm adding DanM to the
CC list.  It does sound like we're closing in.

Nintip: Do you have a reference to the exact bug being repaired, or the exact
patch (or even file) that was changed in the PR3 "repair?"
jar: the bug no is 46253. it was verified on 10/19. So I correct myself , it was
not fixed for PR3 , but was a post PR3 fix.
javi: I could not see the patch for this on the bug report.
So let me ask a dumb question.  If I'm understanding Terry's comment, the 
sequence of events is as follows:

1. PSM-glue receives an encryption request
2. PSM-glue passes that request on to PSM
3. PSM sets a lock before continuing with the encryption
4. PSM determines that user never set password so it does a callback to PSM-glue
5. PSM-glue sets a lock and then puts up the UI for collecting a password

So suppose that PSM-glue tests for the presence of a password first.  If there 
is none, then PSM-glue puts up theUI to collect the password.  After that 
completes, it passes the encryption request on to PSM.

The deadlock is not on any lock in the PSM/psm-glue code.  The deadlock is
caused by having the main thread wait for UI to be displayed and processed,
which depends on the main thread for those services.  Using modal windows breaks
this dependency by allowing a second thread to process UI, or allowing the main
thread to do the UI stuff immediately (depending on which thread invokes the UI)

Testing whether a password is required is not currently available, and would
require changes to PSM and the PSM protocol (I think).  Even if it could be
done, the same issue occurs.  The main thread must put up UI (in psm-glue) to
ask for the password values. This must block waiting for the response, which
leads to the original deadlock.  The solution (again) is to make the UI modal.
making the UI modal , might render the Security Advisor useless. please conisder
that while coming up with a solution.
Here's a comment from danm that appears in bug 46253.

  I think we need to make the security window nonmodal, or stop opening
  nonmodal browser windows on top of it. Is there any chance that can
  be the solution to this bug?

So making the UI modal involves making two windows modal.  The problem before 
was that only one of the UI windows were modal.  Is that correct?
Terry is right.  I'm 90% certain that if we add the modal flag back to
psm-glue's handler for UI events, this problem goes away.

But in doing so, we will probably break Security Advisor and SSL dialogs along
the way.
After swimming through the linkage of chained bug reports starting from 46253, I 
think I might have found the patch that caused this problem.  It's in bug 54860.  
I'm going to try backing this out to see if that was the culprit.
  It was almost certainly bug 54860 that caused the problem.
  Modal windows have a lot of disadvantages. The one I was referring to just 
above is the one where they hog the UI. You have to be careful what you do next 
while you have a modal window up. The security UI is full of links that open 
nonmodal browser windows, which argues for making it nonmodal.
  The one good feature of modal windows is that they know how to unstall I/O 
processing. I suppose it's no coincidence that this bug isn't a problem only on 
Windows, and that it's only on Windows that the PSM UI is modal, since Oct 16? 
You could leave the window nonmodal and try the same trick modal windows use to 
unstall I/O (push/pop a new event queue), if there's a good place to do that.
  Or I could implement that thing I was going to try in bug 56677, forcing new 
windows spawned from modal ones to be modal themselves, regardless of whether 
they were specified modal. Then you could make the PSM UI modal again on all 
platforms, without the consequent UI problems it was causing. Though that does 
open up an interesting open potential for the user to keep stacking modal windows 
up until -- I think if they get 50 deep they'll stall your car.

Javier is working on a fix for this, so I'm re-assigning to him.
Assignee: ddrinan → javi
Dan's proposal for bug 56677 would be exactly the right thing.  The security
advisor would open modal windows if it could, but the Javascript open() call
doesn't let it (because of security concerns?).  Making windows opened by modal
windows also be modal would solve this problem

Dan also identifies the key advantage of modal windows that we are using - event
processing.  While we could work around this ourselves in the psm-glue layer by
push/pop of a new event queue, I'd rather leave such details to other parts of
the code.  Currently we do this by specifying "modal" in the window options.  If
there was another option that provided this benefit without other "bad" features
of modal windows (if there are any) then we would use that.

Our propose patch (in the works) is a "fix-the-symptom" workaround.  It isn't
the correct solution, and if implemented needs to be replaced ASAP with a real
fix.  The 56677 patch is such a fix.  I vote for doing it now.
  There's a patch attached to bug 56677 that might help. Though I don't see it 
making it into the branch. It doesn't seem to be quite perfect -- see the notes 
in that bug. But it will probably solve your problem here by allowing you to make 
the PSM UI window modal on all platforms again.
  Yeesh. Sorry I've been pushing to make that window unmodal. I wasn't expecting 
its modality to actually be a benefit.

I did some work adding the modal flag back to the window->Open call, and that
didn't seem to work.

If someone has a Linux tree they can reliably work with, try reverting
mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp to -r 1.23, and see if that
fixes this for them.

I'll keep working independently to see if I can fix this.
Javi: We are really running out of time here... so any comments need to be 
focused on specific folks. This bug won't get fixed without such pressure at 
this point.

Danm: Can you test the patch you suggested against linux, and report evil side 
effects (if any)?  If problematic, can you also try Javi's suggestion:

     "try reverting mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp to -r 
1.23"

Beard: Can you test the above two items against Mac and report any problems?

Thanks in advance to all participants in this activity,
Jim


Bottom line: What I thought would fix this, didn't work.  I'm back to square one 

in terms of investiagting what went wrong.  :(


Hmm. I've had better luck. On my Linux build, reverting nsPSMUICallbacks.cpp 
keeps "Encrypt Sensitive Info" from hanging the browser -- I suddenly start 
getting the "pick your password" window. And further, with my patch from bug 
56677 included in the mix, windows opened from it seem OK and modal (except for 
parts of the UI, and I think I know what's wrong there too, now.) I think this 
will work.

There's a better patch in bug 56677 now, so I can amend my comment above to state 
simply that the combination of these two changes is, as near as I can tell, 
working. At least on Linux.

Javi: So Danm says you should be done...  Does this work on Mac as well?  If so,
can you get this reviewed and approved asap?  ...or can you list the problems?
For danm, I would add one more test (unfortunately, you have to be inside the 
Netscape firewall to get to this site).

On Linux, goto https://javi.red.iplanet.com:8080

You should see a dialog pop up warning you that the site isn't trusted (it's 
cert was issued by a test CA) and that the names don't match (the cert was 
issued for javi.mcom.com).  If you are able to click through this dialog and 
children window of the security advisor can still receive mouse clicks, then I 
say this fix is good.  (Linux and Mac were the 2 platforms most susceptible to 
this problem.)
  I get no response from http://javi.red.iplanet.com:8080 with either Mozilla or 
Navigator 4.7 (both spin for a bit and shrug; Navigator kindly tells me the 
document contained no data.)
  More notes: fess up time; I've been testing this on the trunk. With the above 
changes in my Linux Mozilla trunk build, attempting to "encrypt sensitive 
information" seems to work. (I get the "pick a password dialog," anyway. After 15 
seconds' wait.) With those same changes in my Linux RTM branch Netscape 
commercial build, I don't get the dialog; it just goes straight to the "Unable to 
convert stored data" alert, as if I had seen the dialog and cancelled.
  Has this stuff by any chance been disconnected in the RTM branch because of 
this bug?

Using build 2000-05-23 on mac and linux the work around works: Here is what I
did to test the work around:

Create a new profile, Select Change Personal SecurityPassword (even though you
don't have a PS password to change), you will get a window for entering a NEW PS
password.  Give the password and close.
Add a new mail account and check the box for saving password.  You will get the
Alert (as they should) that the password should be encrypted to password protect
stored information. You are told to select the Encrypt option in the menu.  OK
this dialog and their mail loads.
After closing app then relaunching mail the password is obsure and still needs
to be encrypted.  You can now select Encrypt from the menu without hanging the
system.  The user will get the Password dialog for entering the previously
recorded encrypted password.
So yes the work around  works!   Basically do a Change Personal Security
Password first then chose Encrypt.
We will try on existing Profiles too. 
This should be release noted. Adding relnoteRTM.
Keywords: relnoteRTM
Whiteboard: [rtm need info] → [rtm need info] relnote-user
..and it works fine on existing profile also. Thanks esther for testing this!!
It should be pointed out that this work-around is far from desirable.  It means 
that the user has to kow in advance that he is going to want to encrypt his 
information.  If he doesn't, and saves any information at all and then decides 
later that he wants to encrypt it, he is out of luck.
rtm-, in lieu of a patch, we have to live with the workaround and release note.
Whiteboard: [rtm need info] relnote-user → [rtm-] relnote-user
Release note: "Mac and Linux. To avoid a crash before encrypting your stored 
passwords for the first time (Tasks>Privacy and Security>Password 
Manager>Encrypt Sensitive Information), select Tasks>Privacy and 
Security>Password Manager>Change Personal Security Password and setup a new 
password. 
*** Bug 60854 has been marked as a duplicate of this bug. ***
Release noted. Removing myself from list of cc's.
*** Bug 61680 has been marked as a duplicate of this bug. ***
I claim that all you need to do to fix this bug is remove the Mac-'n-Linux code
which makes the window nonmodal. Patch below. To retrofit this to the Netscape
6.0 branch, you would also want to copy the fix for bug 56677.

RCS file: /cvsroot/mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp,v
retrieving revision 1.24
diff -r1.24 nsPSMUICallbacks.cpp
109d108
< #ifdef WIN32
111,113d109
< #else
<               (modal && win) ? "menubar=no,height=%d,width=%d,dependent"
< #endif
122,129d117
< #ifdef WIN32
<     if (modal && win) {
<       parentWindow->OpenDialog(jsContext, argv, 3, &newWindow);
<     } else {
<       parentWindow->Open(jsContext, argv, 3, &newWindow);
<     }
<     newWindow->ResizeTo(width, height);
< #else
131d118
< #endif
Oops. I'm rescinding my claim above. Found a more complex case that misbehaves. 
Javier's internal test case mentioned further above, 11-03-2000, horks under my 
patch. Symptoms make it seem as if the patchwork of stalled and active event 
queues created by the resulting modal window festival are to blame.

*** Bug 62036 has been marked as a duplicate of this bug. ***
Raising priority.
Priority: P3 → P1
What happened with the idea of sniffing the "password" token out of the URL?  Is
there a patch that can go on the trunk RSN?
*** Bug 63680 has been marked as a duplicate of this bug. ***
*** Bug 63680 has been marked as a duplicate of this bug. ***
danm:

Whatever became of the work you were doing for this bug?
  Uf. Haven't looked at it recently. I recall we'd decided there were scary event 
processing issues standing in the way of a general solution, and so it would 
probably be harmless and beneficial to hack nsPSMUICallbacks.cpp to switch on the 
URL, opening this one instance of the PSM window modally on all systems, while 
leaving it nonmodal for every other case (but leave it modal in all cases on 
Windows). I guess we didn't decide who got to implement that, but I nominate 
Javier, who knows the most about the URL situation.
  This should work fine on the (Mozilla) trunk. We were also talking about doing 
the same thing on the Netscape 6 branch. This won't work without the fix for bug 
56677, which is currently missing from that branch. I can take care of that part 
if we decide to go ahead with this. But last I heard, this little project never 
made it to the approval stage.

*** Bug 64323 has been marked as a duplicate of this bug. ***
Adding keywords hang since problem is still occurring on 01-24-13-Mtest build...
Keywords: hang
I'm surprised that nobody has nominated this one for nsbeta1 yet.  So I'll do so 
now.
Keywords: nsbeta1
Adding pp on the keywords since problem is only occurring on Linux & Mac 9.04
platforms.......
Keywords: pp
*** Bug 69049 has been marked as a duplicate of this bug. ***
We see this same problem on Solaris Sparc as well.  Margaret
Is this going to be fixed for beta1?
john,

Does this still happen w/ PSM 2?
Worksforme on Linux, Win32 and Mac.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Verified.
Status: RESOLVED → VERIFIED
*** Bug 76514 has been marked as a duplicate of this bug. ***
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.1
Mass changing Security:Crypto to PSM
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.