Created attachment 104455 [details] IMAP alert message box Unable to log in google mail. IMAP alert message box showing alert. Picture of alert message box attached.
Created attachment 104457 [details] IMAP authentication failed
Go to that URL and follow the instructions; gmail only permits OAUTH2 by default, other credential systems are considered "insecure" and you need to explicitly allow this. Notice that "insecure" simply means "you need to let trojitá know the account password".
Thomas is spot-on, closing. This is a GMail anti-feature, there's nothing we can do to change their authentication policies.
On Wednesday 08 March 2017 14:45:20 Thomas Lübking wrote: > https://bugs.kde.org/show_bug.cgi?id=377382 > > --- Comment #2 from Thomas Lübking <thomas.luebking@gmail.com> --- > Go to that URL and follow the instructions; gmail only permits OAUTH2 by > default, other credential systems are considered "insecure" and you need to > explicitly allow this. Note that "insecure" is just by some retarded Google definition. OAUTH2 itself has same security as plain text password authentication. Both plain text password and plain text OAUTH2 tokens can be stolen in the same way. > Notice that "insecure" simply means "you need to let trojitá know the account > password". >
Afaiu google uses OAUTH2 also to hand out different passwords per service, ie. the authentication provided to you MUA won't let you access you playstore account. (Yes, one could simply have different passwords per service itfp...) Some may argue that it prevents you from using shitty passwords (since the tokens are defined by google and M2M what allows them to be quite good compared to the usual "secret"), but you'll still have a shitty master password, so that's void. The downside of OAUTH2 is its complexity which lead to several flawed implementations and my personal observation is that the access is granted too easily by users (ie. the UAC "click nasty ok dialog" problem) Google, Facebook et al. of course have a vivid interest in OID/OAUTH because being your single sign-on service to the entire interwebz bears the opportunity to gather valuable knowledge... ;-)
First, I need to have a working e-mail client. My problem is, Trojita is not working, but evolution works with gmail.
Ok, again: If you want trojitá (or mutt or ...) to work with gmail, go to the url that the dialog links and follow the instructions. Trojiá will be able to log in afterwards. This requires either a setting changed in gmail or an oauth2 implementation in trojitá, the latter is not gonna happen over night (if at all, given Jan considers it an "anti-feature")
Is there any way to trace the "server <--> Trojita IMAP client" handshaking?
(In reply to Szőgyényi Gábor from comment #8) > Is there any way to trace the "server <--> Trojita IMAP client" handshaking? Yes: Menu -> IMAP -> Debugging -> Show IMAP Protocol log. (In reply to Szőgyényi Gábor from comment #6) > My problem is, Trojita is not working, but evolution works with gmail. Perhaps Evolution developers decided to invest their time to add support for GMail's proprietary protocol extension to provide better user experience with GMail out-of-box. Nobody from our developer pool decided that that would be a great use of their time, so Trojita doesn't support AUTH=XOAUTH2 at this point.
Evolution has OAUTH2 support - it's not exaclty proprietary (that wouldn't make sense) but it's certainly far from unobjected, see https://en.wikipedia.org/wiki/OAuth#Controversy Leaving the complexity concerns aside, there's certainly usecase for such system, but it's not "your MUA wants to log into your IMAP server" but more like "webservice foo wants to use your google drive" which you can then individually permit and revoke that permission w/o having to expose (and thus later change) your credentials. Also I frankly wonder how google secures the OAUTH2 access of MUAs - "something™" will have to open a 2nd channel to google and have it ask for confirmation. If "someone" is your local client that opens a browser with a google link, I could imagine this is easily broken (by the local client never opening a visible webpage and just clicking "ok" for the user...) - so the client would have to tell the user "please log into your google account and allow me" *shrug*
On Thursday 09 March 2017 07:24:37 Thomas Lübking wrote: > https://bugs.kde.org/show_bug.cgi?id=377382 > > --- Comment #10 from Thomas Lübking <thomas.luebking@gmail.com> --- > Evolution has OAUTH2 support - it's not exaclty proprietary (that wouldn't make > sense) but it's certainly far from unobjected, see > https://en.wikipedia.org/wiki/OAuth#Controversy OAUTH2 RFC does not specify exact steps for implementation and specially how to exchange and generate tokens. That RFC is too vague for such things, but show examples... Basically we can say that for usage of OAUTH2 you need proprietary extension + try to interpret vague RFC specification for OAUTH2. And IIRC more vendors needs different client implementation of OAUTH2... > Leaving the complexity concerns aside, there's certainly usecase for such > system, but it's not "your MUA wants to log into your IMAP server" but more > like "webservice foo wants to use your google drive" which you can then > individually permit and revoke that permission w/o having to expose (and thus > later change) your credentials. > > Also I frankly wonder how google secures the OAUTH2 access of MUAs - > "something™" will have to open a 2nd channel to google and have it ask for > confirmation. From my understanding of OAUTH2: this protocol is not designed for open source MUAs, but for servers which must not disclose their parts of authentication/token material. Or for closed source application which must contains data which must not be disclosed to user. If you want to use your own application (which is fully under your control) for OAUTH2, then you send just plain text token in protocol (e.g. IMAP) to server (which is equivalent of user+password). And via other channel (HTTP) you need to request for such token. Google's implementation: On Google console website you need to register your application. You will receive public and private tokens for your application. Application tokens then will be used for requesting user tokens (via web page! with user input). This token is IIRC with infinite validity but Google can revoke it at any time. And with this (your private) token you can request via HTTP REST API for time-limited authentication token, which is then used in application protocol for login (e.g. in IMAP). Note that for requesting authentication token you just need to know your private user token and public application. So once your private user token will be stolen anybody can login to your account (if know application). Which means private application token must be kept secret and to correctly use OAUTH2 either application must be closed-source and had obfuscated private application token in binary (and it cannot leak!) or every user generates your own application token (this is only one solution how to properly implement OAUTH2 for open source application). Server needs to have ability to revoke application token at any time. > If "someone" is your local client that opens a browser with a google link, I > could imagine this is easily broken (by the local client never opening a > visible webpage and just clicking "ok" for the user...) - so the client would > have to tell the user "please log into your google account and allow me" This is used for requesting user tokens and caller needs to know private application token. In case whole service is running on server, then user does not see private application token, it is exchanged between Google server and service server. And if correctly implemented, this step is needed only once. From requested token you can request (now without application private parts) time-limited access token which then you will use in IMAP (or other protocol) for authentication. Basically server can track for which protocols is application token (and derived tokens) applicable. If you think more about it you should realise that it is too complicated, hard to properly implement and it has zero benefits for desktop applications (comparing to plain text user+password auth). Security throw obscurity and obfuscating plain text auth in user's applications binaries does not work. And you can perfectly implement time-limited protocol specified access via user+passwords also on server without need for such thing like OAUTH2. So I see absolutely no reason why desktop email client should implement such thing like OAUTH2. It does not bring any security (comparing to plain text), plain text token can be stolen in same way as plain text passwords and proper implementation needs for user to generate application tokens via some Google console service. If you want to use more secure authentication then look for SCRAM-SHA-256 which does not send any plain text information via (IMAP) application protocol. And not for OAUTH2. PS: Probably I used another terminology as specified in OAUTH2, I just wanted to show how such complicated thing is working to answer Thomas's questions.
I tried with an another e-mail provider, not gmail. Trojita still can't log in.
"another e-mail provider" will *certainly* not have lead to that very result, you need to identify the "another e-mail provider" and share the error response in order to get anywhere here.
ping?
Still can't log in. I made a Trojita rebuild today with "git clone git://anongit.kde.org/trojita" After rebuild the version was v0.7-189-g7ca6cf83. Is this the latest? Then I turned on all debugging and logging. Here is my log file, stored $HOME/.cache/flaska.net/trojita/trojita-connection-log: -------------------------------------------------------------------------- 09:35:45.1510 Network Session User's preference changed: NETWORK_EXPENSIVE 09:35:45.1510 Network Session Network is online -> connecting 09:35:45.1510 Network Session Session is open (configuration Wired), online state: online 09:35:45.1527 [task] Imap::Mailbox::OpenConnectionTask OpenConnectionTask: Activated 09:35:45.2457 <<< *** Looking up imap.gmail.com... 09:35:45.2457 [task] conn Resolving hostname... 09:35:45.2477 <<< *** Connecting to imap.gmail.com:993 (SSL)... 09:35:45.2477 [task] conn Connecting to the IMAP server... 09:35:45.2817 <<< *** Negotiating encryption... 09:35:45.2817 [task] conn Starting encryption (SSL)... 09:35:45.3567 <<< *** [Socket is encrypted now; no errors] 09:35:45.3567 [task] conn Checking certificates (SSL)... 09:35:45.3567 [task] conn Checking capabilities... 09:35:45.3577 <<< * OK Gimap ready for requests from 178.48.79.228 r2mb836112693wma 09:35:45.3577 [task] conn Waiting for encryption... 09:35:45.3587 >>> y0 CAPABILITY 09:35:45.3957 <<< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH 09:35:45.3957 <<< y0 OK Thats all she wrote! r2mb836112693wma 09:35:45.3957 [task] conn Logging in... 09:35:51.7537 >>> [LOGIN command goes here] 09:35:52.5827 <<< * NO [WEBALERT https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=AKgnsbtkF18mBu7LXNWaetlSJBapXhuwJy-FdTewNCxyQEkETs3HT8A6dLheSgL3-y_1i-th405WvvuePMkMZUqJpaoX18R-fLLpvDfLt6jOXDj9PXcIGcuHvHTL4VgmlR7z8p7pFbeB6N1-6ponLKotllrJyKTVs0MAf7f4ltGla8TI8uVWg7qXknfcWn1gBn5IC_jsHXY1DeJFyM5HZWPTVcVXT-yS64XmYApHwSQZIFnNGB8QkgE] Web login required. 09:35:52.5837 <<< y1 NO [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure) 09:35:52.5837 Warning: unhandled untagged NO... 09:39:04.0040 [task] Imap::Mailbox::ListChildMailboxesTask Listing stuff below mailbox Failed: Cannot login, you have not provided any credentials yet. 09:39:04.0040 [task] Imap::Mailbox::GetAnyConnectionTask Failed: Cannot login, you have not provided any credentials yet. 09:39:04.0047 [task] Imap::Mailbox::OpenConnectionTask OpenConnectionTask: Logging in... Failed: Cannot login, you have not provided any credentials yet. 09:39:04.0047 [task] conn Logged out. 09:39:04.0057 >>> y2 LOGOUT 09:39:04.0427 <<< * BYE Logout Requested r2mb836112693wma 09:39:04.0427 <<< y2 OK Quoth the raven, nevermore... r2mb836112693wma 09:39:04.0427 [task] Imap::Mailbox::OpenConnectionTask OpenConnectionTask: Logged out. Failed: Asked to die 09:39:04.0427 >>> *** Connection closed. --------------------------------------------------------------------------
> After rebuild the version was v0.7-189-g7ca6cf83. > Is this the latest? Nope, the latest is v0.7-199-gdd2084d, but it doesn't matter, there were no changes to the IMAP LOGIN in there. > 09:35:52.5837 <<< y1 NO [ALERT] Please log in via your web browser: > https://support.google.com/mail/accounts/answer/78754 (Failure) Have you looked at this URL? What troubleshooting steps have you followed? What is your GMail setup -- do you use twofactor authentication? Have you set an application-specific password?
Yes, I followed, but there was nothing interesting. "Have you set an application-specific password?" --> No. Evolution is working, I dont think there is any issue at my gmail account side. Is there any deeper traceing/logging possibility?
> Yes, I followed, but there was nothing interesting. > "Have you set an application-specific password?" --> No. Set it, then, and configure Trojita to use this app-specific password you will have just created for Trojita.. > Evolution is working, I dont think there is any issue at my > gmail account side. There's nothing "WRONG" with your GMail setup, except that it only allows applications which were modified to accommodate GMail's proprietary extension. Without such an app modification, login won't work with your regular GMail password. Evolution includes that modification, Trojita doesn't include it, hence Trojita "doesn't work". Your only chance is to set up an app-specific password for Trojita, or "allow less secure apps to access GMail" as Google calls it. Instructyions are at https://support.google.com/accounts/answer/6010255 > Is there any deeper traceing/logging possibility? There is nothing to debug. You just have to follow the instructions we already gave you.
Thanks. I switched to allow "Less secure apps" and it works now.