81851 - Password Manager never automatically logs me in.

Status: VERIFIED FIXED

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

Description

[Aleksey Nogin]

Password Manager never automatically asks me for a password and never logs me
in. When I go to a site that I have saved a password for, Mozilla would ask me
for that site's password, not for the PM password. And when I ask it to save my
password - still I am not promted to log into Password Manager.

Not, however that if I go into 
Preferences -> Privacy and Cecurity -> Certificates -> Manage Security devices
-> PSM Private Keys -> Login,
and go ahead an log in, then Password Manager will start working (until I
restart Mozilla, obviously).

Also, I could not find anywhere the preferences for how often the PM should ask
me for the password (e.g, once/after x minutes of inactivity/every time/etc).
Preferences -> Privacy & Security -> Passwords does _not_ have it.

I am currently using build id 2001051815 RH7 (installed from the RPMs from
ftp.mozilla.org) on RedHat Linux 7.1

This used to work fine for me with Mozilla 0.9 RH6 RPMs on RedHat 6.2. However
when I upgraded to RedHat 7.1 and installed Mozilla 0.9 RH& RPMs, it stopped
working (I never tried going through the Preferences dialog with 0.9 though).

Comment 1

[Bob Lord]

Reporter, can you create a new profile and try it again?  I wonder if something
got corrupted in a daily build along the way.

Target -> 2.0

Comment 2

[Aleksey Nogin]

I did try it at some point and it didn't help. But I only tried it briefly an I
am not sure what version of Mozilla it was, so I should probably try it again.

However, what I did try a lot of times is to remove *.db *.s *.w (but keep the
prefs.js). If I do that, the next time I request a password to be saved, it
promts me for a new PM password and after I set that, everything goes back to
not working as it used to.

BTW, I am not sure if it is related or it is a separate bug, but in the recent
builds the checkbox that used to say "save this value using Password Manager" or
something along those lines does not have any text next to it, but the checkbox
is still there (and works if I do a manual Login).

Comment 3

[Aleksey Nogin]

Ah, and another thing - I use Mozilla on two machines and have the same problem
on both of them. On second machine (also running RedHat 7.1) the profile was
generated by migrating the Netscape-4 profile using Mozilla-0.9 (installed from
RH7 RPMs) and there I had this problem from the beginning.

Comment 4

[John Unruh]

Workforme with the 5/22 WinNT Netscape 6 build. Make sure you "Encrypt Sensitive 
Information".

Comment 5

[Aleksey Nogin]

I do have "encrypt sencitive information". In any case, this bug prevents
Mozilla from using saved information, no matter encrypted or not, but after I
login manually, it is able to use it.

BTW, I have a suspicion that this bug is restricted to RedHat 7.1 - it does not
seem to occur with Mozilla 0.9 RH6 RPMs on RedHat 6.2, but it does occur with
Mozilla 0.9 RPMs on RedHat 7.1 (although this may be an accidental coincidence).

Comment 6

[Aleksey Nogin]

> In any case, this bug prevents Mozilla from using saved information, no matter
encrypted or 
> not, but after I login manually, it is able to use it.
>
I guess I should better explain what I've just said - what I meant is that even
thought I have no way of checking whether the saved information is actully
encrypted or not, I do know that Mozilla is unable to use that information until
I manually log into the PSM Private Keys Software Security Device.

Comment 7

[Aleksey Nogin]

[Build ID 2001052510] If I do "Edit -> View Saved Data" before manually logging
into the PSM "Software Security Device", I get an "Alert" window saying "Unable
to unlock database" and I do not get prompted for the password. After I manually
log in, I no longer get this message.

Comment 8

[Aleksey Nogin]

Verified that this bug still exists with build id 2001052819 on RedHat Linux 7.1
_with fresh profile_:

1) Created new profile "test"
2) Started mozilla -P test
3) Went to a site that requires authentication (http://members.spamcop.net/)
4) Entered auth info, selected for it to be saved by PSM.
5) Tasks -> Privacy & Security -> Password Manager -> Encrypt sensitive information.
6) Set master password appeared ==> chose password "test".
7) Exited Mozilla.
8) Started mozilla -P test
9) went to http://members.spamcop.net/ ==> was prompted for SpamCop passwd
(saved info _not_ filled in), not Master passwd.
10) Pressed "Cancel" in the passwd dialog.
11) Edit -> Preferences -> Privacy and Security -> Certificates -> Manage
Security Devices -> Software Security Device -> Login
12) Was prompted for master pass ==> entered master pass ("test").
13) Went to http://members.spamcop.net/ ==> was prompted for SpamCop passwd,
this time the saved info was properly filled in.

Comment 9

[Bob Lord]

-> p1 
Maybe related with the changed db passwd problem until the db has been unlocked.

Comment 10

[Javier Delgadillo]

I saw something like this on Linux, and it started to work once I went into my
profile directory and deleted *.rdf and chrome/*

(This would be conents in the /u/javi/.mozilla/javi/<random>.slt/ directory).

Reporter could you try this work around?  (Backup the relevant files if you want
to keep them.)

Comment 11

[Stephane Saux]

Tried Alexsey's steps using
Linux N6 build ID 2001053006.
I was properly prompted to enter my security passwd when visiting a stored
passwd site.
Only differences were: different site (etrade), didn't start with -P but used
the dialog with the set of profiles.
So works for me.
Reporter, can you try more recent build?

Comment 12

[Stephane Saux]

Note: Failure to change password before db has been unlocked bug is 83160.  Not
making it dependent on it, but reporter may want to check it.

Comment 13

[Aleksey Nogin]

Tried removing *.rdf and chrome/* per Javier's suggestion, didn't help (not too
surprising since even creating new profile does not help).

Stephane, what distro did you try this on? I believe (although I never
double-checked it) that while it was working properly with Mozilla 0.9 6x RPMs
on RedHat 6.2, when I upgraded the machine to RedHat 7.1 and installed Mozilla
0.9 7x RPMs, it stopped working (with exactly same profile).

Comment 14

[Aleksey Nogin]

To answer Stephane's question: I am still having this problem when using
2001053115 RH7 RPMs on RedHat 7.1

Comment 15

[Aleksey Nogin]

I noticed that the way RH7 RPMs are currently compiled is that configure in ran
without --enable-crypto and then PSM is built separately by invoking

BUILD_OFFICIAL=1 make BUILD_MODULES=psm2

Could this way of building Mozilla account for this bug (and bug #79318 as well)?

Comment 16

[Christopher Blizzard (:blizzard)]

If I'm supposed to be using --enable-crypto it's news to me.  I try and build
the same way that the nighlies do.  bryer+cls can you guys comment on what I
should be using for the rpms?

Comment 17

[cls]

Yes, --enable-crypto is the new officially sanctioned way to build psm/nss.  The
original stopgap measure of using BUILD_MODULES=psm2 method will still work
(until someone breaks it).  The nightly builds will be switched over to using
--enable-crypto RSN.
 

Comment 18

[Aleksey Nogin]

Well, it was just a guess and it turned out to be a wrong guess. I've recompiled
the RPM with --enable-crypto and it didn't seem to change anything. 

Still, I keep wondering if this bug is caused by the way the RPMs are build.
After all, nobody with non-RPM builds could reproduce it. 

Comment 19

[hawkfan]

I am seeing this on RH7.0 with plain old CVS builds.

Comment 20

[Christopher Blizzard (:blizzard)]

Bug 79318 is definitely a packaging problem and I'm working on that now.  I'm
also going to use --enable-crypto now too.  Who knows?  It might fix the problem. :)

Comment 21

[Christopher Blizzard (:blizzard)]

Bug 79318 is fixed now.  Try pulling down the 0.9.1-pre2 rpm and see if it fixes
this problem.

Comment 22

[Aleksey Nogin]

Unfortunatelly, still no luck.

Comment 23

[Christopher Blizzard (:blizzard)]

OK, then I don't know what's causing it.

Comment 24

[Aleksey Nogin]

Tried the following on a RedHat 6.2 machine with 0.9 RH6 RPMs installed:
- Copied a profile from a RH7.1 machine with May 31 build, where this problem
exists.
- Tried going to a password-protected site for which a password was saved (on a
7.1 machine).
- Was _not_ prompted for the "Master password".
- Quit mozilla, remove *.db from the profile directory, start Mozilla.
- Go to the same site, save password in PSM, quit Mozilla.
- Start Mozilla, go to the same site => now I _was_ prompted for the Master
password.

In other words, this bug probably means that RH 7.1 RPMs have problems
_creating_ the right PSM profile. This also means that in order to see if the
bug is fixed in a certain build, one has to create a new profile for each test
(I haven't done it since May 30, will retest the latest "pre0.9.1" RPMs tomorrow)

Also, tomorrow I will try to see what happens if I copy a "good" profile from a
6.2 machine to a 7.1 machine.

Comment 25

[Aleksey Nogin]

All my attempts at finding a workaround failed. Copying a "good" profile from a
RedHat 6.2 system didn't help.

Comment 26

[Aleksey Nogin]

OK, I did some debugging and I think I am getting somewhere. It turned out that
when I go to a password-protected site before logging in manually, the function
PK11PasswordPrompt
(http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSCallbacks.cpp#117)
gets called (twice!) but fails because of the check for non-NULL prompt at
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSCallbacks.cpp#149

When I log in manually, the same function gets called and goes through without a
problem.

Anybody have an idea why this would happen?

Comment 27

[Aleksey Nogin]

I found the problem!
nsSDRContext::GetInterface is returning uninitialized nsresult instead of NS_OK.
It's just a 1-line trivial fix, can we get it into 0.9.1? Please?
CC'ing thayes since he was the one who wrote that code.

Comment 28

[Aleksey Nogin]

Attachment: Return NS_OK properly.

Comment 29

[Javier Delgadillo]

r=javi

Oops, another in-initialized rv gets returned.

Comment 30

[Christopher Blizzard (:blizzard)]

sr=blizzard

Comment 31

[Aleksey Nogin]

I do not have CVS access, so I'll need somebody's help with checking this in.

Comment 32

[selmer (gone)]

The steps for reproducing this might be limited enough to not stop 091.  Putting
on the radar for other PDT opinions.

Comment 33

[Aleksey Nogin]

In is not too limited. On affected platforms PSM Wallet service is completely
unavailable (unless users know the "manual login" workaround). It's not clear
what platforms are affected, but at least RH 7.x seems to be affected. 

Comment 34

[Christopher Blizzard (:blizzard)]

0.9.1 is out the door already

Comment 35

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 36

[Javier Delgadillo]

Fix checked into trunk

Comment 37

[John Unruh]

Reporter, can you try this again with a build after 6/11 and report your 
findings?

Comment 38

[Aleksey Nogin]

I tried several builds since 06/11, inlcuding 2001061822, never had this problem
again.