419354 - constant annoying master password prompts

Status: RESOLVED DUPLICATE of bug 560793

(MailNews Core :: Backend, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

+++ This bug was initially created as a clone of Bug #236510 +++
The problem I reported in bug 236510 is back again, exactly as before.
It was considered to have been fixed at one time, but now it's back with 
a vengeance.  I suspect the change to the new password manager has something
to do with it.  This regression began at about the time that SeaMonkey 
switched from version 1.5a to version 2.0, but I can't be more specific than 
that.

Please see bug 236510 comment 0 for the original description, and also see
Dan Veditz's insightful analysis in bug 236510 comment 4. 

Bug 236510 was thought to have been fixed by the patch for bug 247417.
I don't know what that patch did, or how it fixed that problem, but I 
hope it will be helpful in solving this problem again.

At present, I have 4 email accounts and 4 news accounts.  NONE of those 
accounts specifies "check for new messages at startup", but All 4 email
accounts, and one news account are configured to "check for new messages
every 10 minutes".

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

In bug 383229 comment 5, Gavin Sharp explained that the password manager ends
up prompting the user for the master password, even though all it really 
wants to do is to ask if the "software security device" (the crypto token 
that does the encryption) is logged in, or not; that is, if the master 
password has been previously entered and is still in effect. 

I suspect that's what's going on here.  The comment in the code that Dan 
cited in bug 236510 comment 4 clearly says that it is NOT the developer's
intent to prompt the user for the mail/news server password, and indeed
it does not do so.  But if any mail/news server passwords are kept by 
password manager, it DOES prompt for the master password.

I believe that the mail/news developer's intent was to NOT prompt the user
in any way, for either server password or for master password.  I suspect
that the code wants to ask if an encrypted password is available, without
prompting the user for the master password, but that the logic for testing
to see if an encrypted password exists now prompts for the master password.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

If this really is a password manager bug (as I suspect), then I think this
bug should be blocking 1.9 rather than (or in addition to) TB3.

Comment 3

[Justin Dolske [:Dolske]]

Dupe of bug 369963? This is basically another side effect of nsIThreadManager, which I think you've noticed has been the cause of quite a few regressions. :-(

AFAIK mailnews is still using the old wallet code, so the new password manager isn't involved.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Justin, in this case, there should be NO master password prompts.  
The solution is not to reduce the number from greater-than-one to one,
but rather to reduce the number of master password prompts to zero.

I think the code wants to check to see if it already has the master password,
and so can get the server password without user intervention, and do so if 
possible.  But if user intervention is necessary, either to answer a server
password prompt or to answer a master password prompt, I believe the intent
is to NOT perform the act that would require the user intervention.
I think this is more like another manifestation of bug 383229.

SM is using the new form field fill-in feature, with the drop-down lists 
that appear below the form field.  I thought that feature was tied to the 
new password manager, but maybe not?

Comment 5

[Justin Dolske [:Dolske]]

(In reply to comment #4)
> Justin, in this case, there should be NO master password prompts.

Sorry, I misunderstood you.

> SM is using the new form field fill-in feature, with the drop-down lists 
> that appear below the form field.  I thought that feature was tied to the 
> new password manager, but maybe not?

Nope, separate code.

Comment 6

[Magnus Melin [:mkmelin]]

So what are the STR for this bug?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Months ago, when no relief for this bug was in sight, I changed my server
configs to stop remembering mail or news server passwords for any mail or 
news servers that are configured to fetch new messages either 
a) on startup or 
b) every N minutes.
I also changed my master password timeout to infinite, so that I would
not be prompted for the master password more than once per session, no
matter HOW long I let my SM sit idle.  

As I recall, the STR are something like this:
1) have several mail accounts (at least two) configured 
   a) to remember server passwords, and 
   b) to fetch mail every N minutes, but not at startup.
2) have a news server that is not configured to save server password,
   but to fetch mail every N minutes.
3) configure SM to ask for a master password if it has not been used for 
   at least M minutes (there is a preference panel for this).

Set M to less than N.  e.g. M=5, N=10.

Then startup the mail/news client, and read news from that news account.
wait N minutes, then see one master password dialog appear for each 
email account configured to remember a password.  Then wait N more 
minutes and watch it happen all over again.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

As I review comment 7, I think what I wrote there about 
> Set M to less than N. 
is not necessary as a condition for this bug, and may be wrong.
That is, perhaps, with M < N, MP password prompts every N 
minutes is correct behavior.  So, I now suggest an alternative:

  Set M to slightly more than N.  

I think that will still reproduce this bug, and shouldn't.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I think this is MAJOR.  The ability to use a timeout with the 
Master Password is a major security feature.  That is is so broken 
with mail/news is a big defeat of a major security feature.

Comment 10

[David :Bienvenu]

is this still an issue with TB? We changed TB to prompt for a master password on startup, if one was set. If this is strictly a SM issue, then we wouldn't block TB on it, so I'm tentatively minusing the blocking flag.

Comment 11

[Magnus Melin [:mkmelin]]

I think it's not? Unless you click cancel in the mp dialog of course, then it will ask you until you just give up and give it the password.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

David, the change to TB "to prompt for a master password on startup, if one 
was set" is only a solution for users whose master password timeout is 
infinite (never times out), which is the default for TB, but is not the only
possible setting.  Users who have finite timeouts still see this.

Comment 13

[Wayne Mery (:wsmwk)]

If this is a regression, we should probably want this for TB3 - nominating.  (or if it's not, remove the keyword)

Comment 14

[Mark Banner (:standard8)]

(In reply to comment #7)
> Then startup the mail/news client, and read news from that news account.
> wait N minutes, then see one master password dialog appear for each 
> email account configured to remember a password.  Then wait N more 
> minutes and watch it happen all over again.

We've just fixed the pop3 and smtp parts of this in bug 338549, bug 557622 and bug 557625. Bug 560793 would fix the news part - hence adding dependency.

Comment 15

[Mark Banner (:standard8)]

(In reply to comment #14)
> (In reply to comment #7)
> > Then startup the mail/news client, and read news from that news account.
> > wait N minutes, then see one master password dialog appear for each 
> > email account configured to remember a password.  Then wait N more 
> > minutes and watch it happen all over again.
> 
> We've just fixed the pop3 and smtp parts of this in bug 338549, bug 557622 and
> bug 557625. Bug 560793 would fix the news part - hence adding dependency.

This is still true and valid. However, now I revisit this, I don't think we need multiple bugs to cover the remaining (single) news issue. Therefore I'm marking this as a duplicate of bug 560793, as that covers the news issue.