VM

not clearing wrong password

Bug #886384 reported by John Hein
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
Fix Released
Low
Uday Reddy

Bug Description

trunk rev 1242

My password changes on an upstream imap server. When I tried to 'g' mail from that server (configured in vm-spool-files), vm never cleared the bad password from vm-imap-passwords. I expected to get ...

IMAP password for user@server [inbox] incorrect

... once, but got it every time I hit 'g' to get mail from that server. It seems that in the past, I've had this happen, but the second 'g' caused a new prompt for password.

Side note: it also takes a _long_ time (two+ minutes) to return control to me when 'incorrect password' happens [1]. This may be an old bug. I recall impatiently using multiple C-g's to break out of this situation in the past at some point.

Related bugs:
 bug 729568 (doesn't apply - not a read only folder)
 bug 822578 - looks very similar - maybe that fix was not committed to the trunk?

After turning on imap logging, I see about 20-25 of these trace buffers...

========================================
Starting IMAP session Fri Nov 4 14:26:21 2011^M
-- connecting to fb8:1143^M
* OK [CAPABILITY IMAP4REV1 AUTH=LOGIN IDLE] IMAP4rev1 DavMail 3.9.4-trunk server ready^M
-- connected for movemail^M
VM CAPABILITY^M
* CAPABILITY IMAP4REV1 AUTH=LOGIN IDLE^M
VM OK CAPABILITY completed^M
VM LOGIN <parameters omitted>^M
VM NO LOGIN failed^M
VM LOGOUT^M
* BYE Closing connection^M
VM OK LOGOUT completed^M

Process IMAP connection broken by remote peer
ending IMAP session Fri Nov 4 14:26:24 2011^M
========================================

[1] The 20-25 attempts explains the two+ minutes.

And a report in the mini-buffer...

Variable binding depth exceeds max-specpdl-size

And that probably explains why I only get 20-25 attempts - it would probably go on forever otherwise.

Tags: 7.19 imap

Related branches

Revision history for this message
John Hein (xpqheqdvq4) wrote :

workarounds when you know you've changed your password(s):
 - kill/restart emacs (is there a way to unload all of vm without killing emacs?)
 - (setq vm-imap-passwords nil) to clear the cached passwords

(I have not yet tried using the .authinfo.gpg feature yet - that will likely avoid this problem, too?)

Revision history for this message
John Hein (xpqheqdvq4) wrote :

John Hein wrote at 22:06 -0000 on Nov 4, 2011:
 > bug 822578 - looks very similar - maybe that fix was not committed to the trunk?

vm-imap.el is the same on 8.2.x and the trunk.

Revision history for this message
John Hein (xpqheqdvq4) wrote :

> vm-imap.el is the same on 8.2.x and the trunk.

Well, it was until rev 1245. Trying the tip of trunk (1248) now.

Revision history for this message
Uday Reddy (reddyuday) wrote :

My guess is that this problem has always been there in VM. We located it and fixed it for server folders, but the local folder stuff is probably using separate code which might still have the problem.

As you know, restarting Emacs gets rid of the cached bad password. So that is a work-around.

Cheers,
Uday

Changed in vm:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Uday Reddy (reddyuday)
milestone: none → 8.2.0
tags: added: 7.19 imap
Revision history for this message
Uday Reddy (reddyuday) wrote : Re: [Bug 886384] [NEW] not clearing wrong password

With the current trunk revision, 1248, I find that wrong passwords don't
cause any problem. The messages displayed were:

Checking for new mail for d:/Home/udr/mail/udrtest1...
IMAP password for udrtest1:INBOX incorrect
vm-imap-make-session: Need password for udrtest1:INBOX for movemail

----

The IMAP session trace shows:

Starting IMAP over SSL session Sat Nov 05 12:48:46 2011

-- connecting to imap.gmail.com:993

* OK Gimap ready for requests from 77.100.13.194 md11if519462wib.316

-- connected for movemail

VM CAPABILITY

* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH

VM OK Thats all she wrote! md11if519462wib.316

VM LOGIN <parameters omitted>

VM NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)

VM LOGOUT

* BYE Logout Requested md11if519462wib.316

VM OK Quoth the raven, nevermore... md11if519462wib.316

Process IMAP over SSL finished
ending IMAP session Sat Nov 05 12:48:49 2011

Revision history for this message
Uday Reddy (reddyuday) wrote :

Revision 1250 forgets wrong passwords.

Changed in vm:
status: Triaged → Fix Committed
importance: Medium → Low
Revision history for this message
John Hein (xpqheqdvq4) wrote :

I only see rev 1248 on the tip of the trunk.

Revision history for this message
Uday Reddy (reddyuday) wrote : [Bug 886384] Re: not clearing wrong password

John Hein writes:

> I only see rev 1248 on the tip of the trunk.

Yes, this version should be already "correct" in that it should recover from
bad passwords without retrying for ever. There should be no infinite loop.
Are you still seeing an infinite loop?

Cheers,
Uday

Revision history for this message
Uday Reddy (reddyuday) wrote :

John, to be clear, what you reported is a combination of a bug and a wishlist item. The bug is that VM went into an infinite loop (broken only by an overflow). The wishlist item is that VM should forget a cached password when it doesn't work.

I have implemented the wishlist item in revision 1250.

But I couldn't reproduce the bug (infinite loop) with revision 1248, as I mentioned in response #5. Can you double check that you are indeed using 1248 and it is compiled correctly.

If so, can you put a debug-on-entry on vm-imap-make-session and and let me know what arguments it getting passed?

Changed in vm:
status: Fix Committed → In Progress
Revision history for this message
John Hein (xpqheqdvq4) wrote :

Indeed - no infinite loop in 1248 (presumably 1245+).
And I agree about the two separate issues - you had said there was a 'forget bad passwords' change in 1250 that I was going to try as well, but 1248 is the latest I see at http://bazaar.launchpad.net/~vm/vm/trunk/.

Revision history for this message
Uday Reddy (reddyuday) wrote :

Ok, I have uploaded 1250. I have already tested it. So, no need to worry.

Cheers,
Uday

Changed in vm:
status: In Progress → Fix Committed
Revision history for this message
John Hein (xpqheqdvq4) wrote :

What, me worry? (apologies to Alfred E. Neuman)

Thanks. Both aspects of this bug are squashed on the trunk as of rev 1250.

Uday Reddy (reddyuday)
Changed in vm:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.