Bugzilla – Bug 1224160
alpine forgets login credentials saved upon server issue
Last modified: 2024-05-29 09:03:35 UTC
Each time imap.suse.de has hickups alpine forgets credentials stored in .pinepw it seems. Flow is like 1) server issue, auth with stored creds fails 2) alpine prompts for password 3a) I press ctrl-C, cancelling auth 3b) I type something, alpine asks whether to remember, I say no, auth fails 4) server OK again 5a) re-authentication - alpine asks for password, doesn't try OK creds from .pinepw 5b) quit & restart alpine, alpine asks for password, doesn't try OK creds from .pinepw which means I have to renew the app-specific password each time there's a server issue. Expected behavior: alpine keeps credentials in .pinepw until I say "yes" to "remember password for future logins", do _not_ forget/throw away entries upon authentication fail. > rpm -qi alpine Name : alpine Version : 2.26 Release : bp155.5.7 Architecture: x86_64 Install Date: Wed May 24 10:19:26 2023 Group : Productivity/Networking/Email/Clients Size : 10312891 License : Apache-2.0 Signature : RSA/SHA512, Mon May 22 12:47:41 2023, Key ID 8a49eb0325db7ae0 Source RPM : alpine-2.26-bp155.5.7.src.rpm Build Date : Mon May 22 12:47:09 2023 Build Host : lamb15 Relocations : (not relocatable) Packager : https://bugs.opensuse.org Vendor : openSUSE URL : https://alpineapp.email/ Summary : Mail User Agent Description : Alpine is a display-oriented email client that is suitable for both the inexperienced email user as well as for the most demanding of power users. Alpine is based on the Pine® Message System, which was also developed at the University of Washington. Alpine can be learned by exploration and the use of context-sensitive help. The user experience is highly customizable through the use of the Alpine Setup command. Distribution: SUSE Linux Enterprise 15 SP5
I debugged this and found that alpine already deletes the credentials from .pinepw before prompting for the password in step 2. Then I asked upstream and got the answer that this behavior is intentional: --- snip --- this appears documented in the release notes in version 2.25: * Alpine deletes, from its internal memory and external cache, passwords that do not work, even if they were saved by the user. This is because the problem that is being addressed is to have servers that disconnect after the first failure, make the user have a chance to enter the password during the second attempt. I can see that other models could be used in this case, but that is the reason why this was implemented. --- snap --- The question now is: How do your server hickups look like and would it be possible for alpine to distinguish them from authentication failures due to invalid credentials?
(In reply to Reinhard Max from comment #1) > I debugged this and found that alpine already deletes the credentials from > .pinepw before prompting for the password in step 2. > > Then I asked upstream and got the answer that this behavior is intentional: > > --- snip --- > this appears documented in the release notes in version 2.25: > > * Alpine deletes, from its internal memory and external cache, passwords > that do not work, even if they were saved by the user. > > This is because the problem that is being addressed is to have servers that > disconnect after the first failure, make the user have a chance to enter the > password during the second attempt. I can see that other models could be > used in this case, but that is the reason why this was implemented. It sounds like the issue is that there is no way to prompt for a password for the second attempt without deleting the password from the external cache? I don't see a particular reason do scrap the external cache - if the second manual password entry succeeds pine can always aks whether it should remember the password (and then override) or if the user answers no, remove. But I do not think removing the password from the external cache when the second attempt is interrupted (Ctrl-C) or when it also fails (user simply entering <enter>). For the actual failure what I'd ideally like to see is at the point pine asks me for the password on the 2nd try to be able to tell it "try later with the stored password". That said, the only workaround for me at the moment is probably keeping a backup of the .pinepw file and copying it back and re-start pine? > --- snap --- > > The question now is: How do your server hickups look like and would it be > possible for alpine to distinguish them from authentication failures due to > invalid credentials? It's the usual imap.suse.de "hickups" when the userdb vanishes. apine doesn't tell me any details about the authentication failure. I suppose it's not a timeout or some sort but instead a "true" authentication failure (aka wrong username/password). It's the servers fault (misconfiguration) of course and only temporary.
(In reply to Richard Biener from comment #2) > It sounds like the issue is that there is no way to prompt for a password > for the second attempt without deleting the password from the external cache? Yes, if I understood alpine's architecture correctly the only way for the lower layer that detects an authentication failure to communicate to the upper layer that the credentials didn't work is to delete them, so that the upper layer has to query the user again instead of reading it from the caches. > I don't see a particular reason do scrap the external cache - if the second > manual password entry succeeds pine can always aks whether it should remember > the password (and then override) or if the user answers no, remove. Yes, that would probably be better from a user perspective, but I guess the current solution was less intrusive to implement. > But > I do not think removing the password from the external cache when the > second attempt is interrupted (Ctrl-C) or when it also fails (user > simply entering <enter>). At that point in time the password is already gone as it gets deleted immediately when the first attempt fails. > For the actual failure what I'd ideally like to see is at the point > pine asks me for the password on the 2nd try to be able to tell it > "try later with the stored password". I agree that this behavior would be preferable, similar to the dialogs that browsers have for using and replacing stored passwords. > That said, the only workaround for me at the moment is probably keeping > a backup of the .pinepw file and copying it back and re-start pine? Yes, but reopening the respective mail folder might even be enough in case you prefer that over a full restart. > It's the usual imap.suse.de "hickups" when the userdb vanishes. I am not sure if I ever experienced such a hickup, as I wasn't using imap.suse.de until recently, and now I use it with the web mailer rather than through a local IMAP client. > apine doesn't tell me any details about the authentication failure. Please run alpine with "-d 9" and send me ~/.pine‐debug1 when the hickup has happened again. FYI: Up to and including debug level 9 no secrets get logged, but stuff like the IMAP host and user name. > It's the servers fault (misconfiguration) of course and only temporary. Sure, but let's see if these faults are distinguishable from mistyped credentials, so that we can work around the misconfiguration from our side.
Created attachment 875182 [details] pine debug log Happened (maint window) again.
Thanks, it contains what I was hoping for (and I also got similar errors trying to access my email via roundcube): 08:36:55.151365 IMAP DEBUG 08:36:55.151365: 00000000 NO [UNAVAILABLE] Account is temporarily unavailable. So, it is a temporary error that alpine should be able to distinguish from errors due to invalid or expired credentials.
(In reply to Reinhard Max from comment #5) > Thanks, it contains what I was hoping for (and I also got similar errors > trying to access my email via roundcube): > > 08:36:55.151365 > IMAP DEBUG 08:36:55.151365: 00000000 NO [UNAVAILABLE] Account is temporarily > unavailable. > > So, it is a temporary error that alpine should be able to distinguish from > errors due to invalid or expired credentials. Agreed. I'm not sure todays outage was the same as the last - I'll see if it's another reason when it happens the next time and keep you updated.