Bug 404990 - Sign in with Google temporarily disabled for this app
Summary: Sign in with Google temporarily disabled for this app
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: 5.12.2
Platform: Arch Linux Linux
: HI normal
Target Milestone: 4.10
Assignee: kdepim bugs
URL:
Keywords:
: 405185 410027 410077 410225 410327 411248 412873 413472 415280 419913 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-03-02 15:15 UTC by PK
Modified: 2023-06-05 16:02 UTC (History)
94 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Error message for gmail sign in (65.83 KB, image/png)
2019-03-05 21:02 UTC, Joco
Details
Greyed out password for Gmail (86.15 KB, image/png)
2019-03-07 14:49 UTC, Joco
Details
Greyed out authentication for Gmail (69.73 KB, image/png)
2019-03-07 14:49 UTC, Joco
Details
attachment-31863-0.html (1.95 KB, text/html)
2019-08-08 15:32 UTC, Ekkehard Blanz
Details
attachment-26075-0.html (1.98 KB, text/html)
2019-08-09 15:29 UTC, Ekkehard Blanz
Details
kmail settings (2.53 MB, image/png)
2019-10-16 14:34 UTC, PK
Details
attachment-13124-0.html (1.18 KB, text/html)
2020-03-04 18:03 UTC, David Sijbesma
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PK 2019-03-02 15:15:15 UTC
SUMMARY
It is impossible for me to set up a gmail account in Kmail. I use imap and OAuth2. When i select "yes"  in the message sent to my mobile phone, there appears a screen of the kmail account whizzard saying: "Sign in with Google temporarily disabled for this app". This happens on Debian testing but today I tried on Neon User Edition too and got the same result.

STEPS TO REPRODUCE
1. start with a clean Debian testing/Neon User Edition installation
2. try to create a gmail account in kmail using the account whizzard
3. in my case (imap OAuth2) it ends with a screen saying: "Sign in with Google temporarily disabled for this app" 

OBSERVED RESULT
No gmail account is set up

EXPECTED RESULT
I get a working gmail account in kmail

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian testing / Neon User Edition
(available in About System)
KDE Plasma Version: Debian testing 5.14.5 / Neon User Edition 5.15.2
KDE Frameworks Version: Debian 5.54.0
Qt Version: Debian 5.11.3

ADDITIONAL INFORMATION
Comment 1 Joco 2019-03-05 21:02:24 UTC
Created attachment 118581 [details]
Error message for gmail sign in

Error message displayed by Kontact/Kmail following Gmail authentication failure.
Comment 2 Daniel Vrátil 2019-03-07 11:38:19 UTC
There's currently an issue with the API keys used by Kontact to authenticate against Google. We are working on getting the app re-enabled again for new users.

For now, you can use PLAIN authentication method (instead of XOAUTH2/Gmail) to authenticate with Gmail (if you use 2-factor authentication you will need to generate an app-specific password on accounts.google.com).
Comment 3 Joco 2019-03-07 14:49:10 UTC
Created attachment 118627 [details]
Greyed out password for Gmail
Comment 4 Joco 2019-03-07 14:49:35 UTC
Created attachment 118628 [details]
Greyed out authentication for Gmail
Comment 5 Joco 2019-03-07 14:51:43 UTC
Thank you for your speedy response, glad to hear that work is ongoing.

Unfortunately I don't think the workaround will be successful - though very happy to be contradicted.

I'm very new to Kontact/Kmail but I believe there are two ways to add mail accounts - within the Configure - Kontact window select Accounts and you then have an option to 'Add...' either 'Add Mail Account' or 'Custom Account' 

If you go for the first option 'Add Mail Account' then there is no option to choose the PLAIN authentication method - it simply takes you through to the previously posted dialogue which results in the error.

With the second option 'Custom Account' - when you enter details of a Gmail account it greys out both the password and the authentication options.  See attached screenshots.  Again you are back to the previous error.

I do use Google 2FA and have created an application specific password, but due to the above 'greying' out there is nowhere to enter this.

My OS is Kubuntu 18.04 and Kontact is version 5.7.3.  I suspect there will be no way for Gmail users to add accounts until the wider bug is corrected?

Again thanks for your help.
Comment 6 PK 2019-03-07 17:05:02 UTC
Dear Joco,
I tried setting up my gmail-account in kmail without succes. This afternoon I looked in the /Settings menu under /Kmail Settings (bottom entry). Then with "Accounts"  highlighed on the left side (upper entry) I noticed that everything in the "send"  and " receive" tabs was already filled out!
I only had to give the generated password in both tabs and kmail worked like a charm. Easier than i thought.
Comment 7 Antonio Rojas 2019-03-07 17:32:55 UTC
*** Bug 405185 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Vrátil 2019-03-11 14:51:54 UTC
What version of Kontact do you have? Indeed in previous versions it wasn't possible to switch to other authentication methods when the server URL was imap.gmail.com, but in the more recent version (I think since KDE Applications 18.04 or 18.08 - that's Kontact 5.8 or 5.9) it is possible if you select "Custom Account" -> "IMAP" then in the "Advanced" tab, the authentication method combo box should be accessible and you should be able to select PLAIN method and enter your username and password normally.
Comment 9 Joco 2019-03-11 15:10:07 UTC
Daniel -  Thanks for your reply.  I'm using Kubuntu 18.04 LTS and Kontact is version 5.7.3.  I only downloaded it this month (switching from Ubuntu), so that is the version of Kontact that is included in the LTS version of the OS.  Sounds like I could try updating to a newer version of Kontact or Kubuntu (or wait for the bug to be fixed).  Thanks for your help.

PK - Thanks for your reply too; however this didn't work, probably due to version differences.
Comment 10 Unknown 2019-03-11 16:15:52 UTC
I was having similar issues with Kmail in KDE Neon where Google was saying Kmail was "Not Verified by Google" (see https://bugs.kde.org/show_bug.cgi?id=405185). Though the error was different, my bug was marked a duplicate of this bug. After receiving recently updated packages (thought Kmail still seems to be the same version), the bug seems to have gone and I can successfully add my gmail account. Interesting, though, Google named the app "Akregator" and not "Kmail".
Comment 11 Unknown 2019-03-11 16:16:40 UTC
Sorry, "Akonadi" not "Akregator".
Comment 12 bwl 2019-07-25 08:35:08 UTC
Software
openSUSE Tumbleweed 20190723
KDE Plasma version: 5.16.2
KDE Frameworks version: 5.59.0
Qt version: 5.13.0
Kernel version: 5.2.1-1-default
OS Type: 64-bit

Hardware
Processors: 8 x AMD Ryzen 5 2500U wit Radeon Vega Mobile Gfx
Memory: 7.5 GiB of RAM
Comment 13 Wolfgang Bauer 2019-07-26 12:53:13 UTC
*** Bug 410027 has been marked as a duplicate of this bug. ***
Comment 14 Wolfgang Bauer 2019-07-26 12:53:37 UTC
*** Bug 410225 has been marked as a duplicate of this bug. ***
Comment 15 PK 2019-07-26 14:19:27 UTC
So bwl what is your story? Apart from that you are using openSUSE Tumbelweed etc?
If i had to take a gamble I would say that you can't (again) setup a Gmail account in Kmail.
At least that is at the moment my problem. 
I am using Debian (bullseye) testing. Plasma 5.14.5.
The issue, dating from march 2019, repeats itself. I get the same error message from Google and my gmail-account is not set up in Kmail.
Comment 16 Mark Stanton 2019-07-26 17:17:16 UTC
(In reply to Wolfgang Bauer from comment #13)
> *** Bug 410027 has been marked as a duplicate of this bug. ***

I am not convinced this (ie my bug entry 410027 being recorded as a duplicate of this bug) is correct.

I am not trying to set up a new account. The account has been set up for years, and KMail has been functioning perfectly well accessing it until recently.

It may be that the cause is the same, though.
Comment 17 bwl 2019-07-27 10:29:11 UTC
gmail account is valid and integrates with KDE/akonadi on a parallel system (see below):

Operating System: openSUSE Tumbleweed 20190723
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0
Kernel Version: 5.2.1-1-pae
OS Type: 32-bit
Processors: 2 × Intel® Core™2 Duo CPU E4500 @ 2.20GHz
Memory: 1.9 GiB of RAM

When initiated on this system (32-bit) a token was generated by google which replaced the password. With the new (64-bit) system no token is being offered by google.  Google simply generates the message "Sign in with Google temporarily disabled for this app This app has not yet been verified by Google in order to use Google sign in"  Receiving status reads as "ready". Switching from Gmail authentication to PLAIN or LOGIN yields "Server is not available"

The 64-bit system is a fresh install with no modification.  Previous attempts made to resolve with older builds clearing the akonadi database etc. with no effect.  Therefore new build.

What (if any) further info can I supply to help resolve this?

Kind regards
Barry
Comment 18 Cherkah 2019-07-29 06:57:01 UTC
Système d'exploitation : Debian GNU/Linux 
Version de KDE Plasma : 5.14.5
Version de Qt : 5.11.3
Version de KDE Frameworks : 5.54.0
Version de noyau : 4.19.0-5-amd64
Type de système d'exploitation : 64-bit
Processeurs : 4 × Intel® Core™ i5-6300HQ CPU @ 2.30GHz
Mémoire : 11,6 Gio de mémoire vive


i get the same probleme on fresh install (kde + debian).
Comment 19 Christoph Feck 2019-07-29 12:54:24 UTC
*** Bug 410327 has been marked as a duplicate of this bug. ***
Comment 20 Wolfgang Bauer 2019-07-29 14:05:01 UTC
*** Bug 410077 has been marked as a duplicate of this bug. ***
Comment 21 Dennis Schridde 2019-07-30 04:41:15 UTC
Could we add "oauth" and "gmail" to the bug summary?  That might help others find this report and prevent more duplicates, especially under the circumstance that the error message Google gives is localised into the user's language and will thus likely not match the English error message in this bug's summary.
Comment 22 Antonio Rojas 2019-07-30 06:45:41 UTC
*** Bug 410077 has been marked as a duplicate of this bug. ***
Comment 23 Leandro Ramos 2019-07-30 18:55:57 UTC
Same issue here: Fedora Rawhide 31 - KMail 5.11.3
And here: Debian Buster - KMail 4.18
Comment 24 Marcelo Escobal 2019-07-31 19:53:41 UTC
Same issue:

Kubuntu 19.04 (fresh install) 
Kde Plasma: 5.15.4
Kde Frameworks: 5.56.0
Qt: 5.12,2
Kernel: 5.0.0-21
Comment 25 David Bate 2019-08-02 00:40:06 UTC
Same issue: was working after setting to plain auth from GMAIL, but as of today will not sync at all with any auth settings. 

KDE Neon 5.16 (fresh install) 
Kde Plasma: 5.16.4
Kde Frameworks: 5.60.0
Qt: 5.12.3
Kernel: 5.0.0-24
Comment 26 David Sijbesma 2019-08-02 10:30:39 UTC
Manjaro and Arch linux latest updates also failing
Kde Plasma: 5.16.3/4
Kde Frameworks: 5.60.0
Qt: 5.13
Kernel: 5.2.2-1-MANJARO
Comment 27 Eugene 2019-08-05 00:20:15 UTC
The same damn thing on Kubuntu 19.04. I am not able to set up KMail to work with GMail! Ans PLAIN is not working as a workaround BTW.
Comment 28 davidblunkett 2019-08-07 18:21:28 UTC
Just ran into this bug - bloody hell it's annoying.  It is working fine on a parallel system (presumably the old token is still valid on that?).

The bodge to disable kmail's "gmail" authentication by switching from "imap.gmail.com" to and IP address and using PLAIN authentication has worked for me but this is a poor fix.

I can't find any way to switch to PLAIN without nobbling the address which is really annoying but this should (at least) be an available option.
Comment 29 Dirk Davidis 2019-08-07 18:33:35 UTC
I think this issue just needs to be solved. i mean Akonadi and Gmail needs to work with oauth. and hopefully it needs to be solved asap
Comment 30 Kishore Gopalakrishnan 2019-08-08 02:09:00 UTC
(In reply to davidblunkett from comment #28)
> Just ran into this bug - bloody hell it's annoying.  It is working fine on a
> parallel system (presumably the old token is still valid on that?).
> 
> The bodge to disable kmail's "gmail" authentication by switching from
> "imap.gmail.com" to and IP address and using PLAIN authentication has worked
> for me but this is a poor fix.
> 
> I can't find any way to switch to PLAIN without nobbling the address which
> is really annoying but this should (at least) be an available option.

Are you sure about the address thing? I have been able to use it by just switching the authentication to SSL/TLS, port 993, PLAIN (still using imap.gmail.com).
Comment 31 Wolfgang Bauer 2019-08-08 09:52:03 UTC
*** Bug 410700 has been marked as a duplicate of this bug. ***
Comment 32 Wolfgang Bauer 2019-08-08 09:57:24 UTC
Apparently it's not really a bug in the software, but rather a policy problem that needs to be solved.
https://mail.kde.org/pipermail/kde-pim/2019-August/042400.html
Comment 33 Ekkehard Blanz 2019-08-08 15:32:02 UTC
Created attachment 122012 [details]
attachment-31863-0.html

Sure Wolfgang,

the Google authentication not working I can see as an issue between the
Google Goliath and the Akonadi PIM David (guess who's gonna win).  But what
about the "Custom Account" route not letting me fully customize the
settings, but instead forcing me to use the (broken) Google authentication
method as soon as it detects the Google IMAP server?  In "Custom" mode, I
should be in full control of all settings, even to mess them up royally if
I so desire - no?

Ekkehard

On Thu, Aug 8, 2019 at 2:57 AM Wolfgang Bauer <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=404990
>
> Wolfgang Bauer <wbauer@tmo.at> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |wbauer@tmo.at
>
> --- Comment #32 from Wolfgang Bauer <wbauer@tmo.at> ---
> Apparently it's not really a bug in the software, but rather a policy
> problem
> that needs to be solved.
> https://mail.kde.org/pipermail/kde-pim/2019-August/042400.html
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 34 Wolfgang Bauer 2019-08-09 12:28:17 UTC
(In reply to Ekkehard Blanz from comment #33)
> But what
> about the "Custom Account" route not letting me fully customize the
> settings, but instead forcing me to use the (broken) Google authentication
> method as soon as it detects the Google IMAP server?  In "Custom" mode, I
> should be in full control of all settings, even to mess them up royally if
> I so desire - no?
I see, so your bug report actually was about not being able to change the settings, which of course is not a duplicate of this.
I'll reopen your report then (you should have been able to do that yourself btw... ;-) )
Comment 35 Ekkehard Blanz 2019-08-09 15:29:05 UTC
Created attachment 122042 [details]
attachment-26075-0.html

Yup - I could have made that clearer.  I mentioned the "other bug" just to
help prioritize this bug, as "my bug" annihilates the only workaround.

> I'll reopen your report then (you should have been able to do that
yourself
btw... ;-) )
I didn't know that I could do that.  But let me take this opportunity to
say that here my ignorance is really bliss, as this ignorance stems from
having to file KDE bug reports only VERY rarely (once in several years as a
moderate user), which, and that cannot be stressed enough, is a darn good
thing!!!

On Fri, Aug 9, 2019 at 5:28 AM Wolfgang Bauer <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=404990
>
> --- Comment #34 from Wolfgang Bauer <wbauer@tmo.at> ---
> (In reply to Ekkehard Blanz from comment #33)
> > But what
> > about the "Custom Account" route not letting me fully customize the
> > settings, but instead forcing me to use the (broken) Google
> authentication
> > method as soon as it detects the Google IMAP server?  In "Custom" mode, I
> > should be in full control of all settings, even to mess them up royally
> if
> > I so desire - no?
> I see, so your bug report actually was about not being able to change the
> settings, which of course is not a duplicate of this.
> I'll reopen your report then (you should have been able to do that yourself
> btw... ;-) )
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 36 easylee 2019-08-11 03:19:51 UTC
I too just did a fresh install of KDE 19.04...partly so that I could get my Gmail account into the Kontact PIM enviro and am getting that same error:

    "Sign in with Google temporarily disabled for this app
     This app has not been verified yet by Google in order to use           
    Google Sign In."

I've tried to setup my account using IMAP...and have tried two different App Specific passwords and can't complete the account.

Maybe I've missed it in this thread, but is someone supposed to contact Google/Alphabet to get Kontact/Kmail "approved"?
Comment 37 bwl 2019-08-15 07:59:58 UTC
easylee has asked a valid question.  Has Google/Alphabet been contacted?  By who, when? If not why not?  Who owns this problem?  Why no recent activity on this?
No malice intended.
Kind regards,
Barry
Comment 38 Cherkah 2019-08-15 16:07:31 UTC
realy who is in charge to this issue?
there are 3 weeks that i can not use my gooogle account with kmail!!

does kmail is a bad spyware that google reveal? should i stop use it? what about my others accounts?

a kde/kmail user!
Comment 39 Mark Stanton 2019-08-15 16:27:00 UTC
It's "simply" Google's new API implementation, but no, I don't know why access hasn't been organised for KMail. Evolution has access to GMail.

an ex-KMail user, due to this issue being the final straw.
Comment 40 Uncle Mez 2019-08-16 10:24:02 UTC
Hello Team !
Just back to KDE after a long long trip now and found my dearest Kmail not working with Gmail lire said many here "Akonadi is kind of broken..."

Possible to get this fixed so we can be back on the track again !
Thank You for your works

Blessings !
Comment 41 Dirk Davidis 2019-08-16 11:03:00 UTC
until this has not been fixed working with kde is a mess ... thunderbird or evolution are no real alternative ... so is there any timeline when this gets fixed?
Comment 42 Kishore Gopalakrishnan 2019-08-16 11:05:47 UTC
(In reply to Dirk Davidis from comment #41)
> until this has not been fixed working with kde is a mess ... thunderbird or
> evolution are no real alternative ... so is there any timeline when this
> gets fixed?

Are you not able to use the workaround mentioned in comment 2?
Comment 43 carl 2019-08-16 12:14:22 UTC
https://www.reddit.com/r/kde/comments/cj7t7c/kmail_doesnt_let_me_sign_in_with_gmail/evccssj/

Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with KMail privacy policy.
Comment 44 Ekkehard Blanz 2019-08-16 16:13:36 UTC
> Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with
> KMail privacy policy.
I don't understand what this means in practical terms.  Does it matter whether 
we call it a Kmail / Akonadi bug or Google being unhappy with what it does?  
After all, we are talking about gmail.

The way I see it (and maybe I am wrong, then tell me) it can be fixed two 
ways: One is to convince Google that they are wrong and change their ways, the 
other would be to say we accept it as a feature bug and we fix it to make 
Google happy.  I frankly don't care which route is taken as long as it gets 
done.  If it was me, I knew which basket to put my eggs in, but I wouldn't 
impose...


On Friday, August 16, 2019 5:14:22 AM PDT carl wrote:
> https://bugs.kde.org/show_bug.cgi?id=404990
> 
> carl <schwancarl@protonmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> CC|                            |schwancarl@protonmail.com
> 
> --- Comment #43 from carl <schwancarl@protonmail.com> ---
> https://www.reddit.com/r/kde/comments/cj7t7c/kmail_doesnt_let_me_sign_in_wit
> h_gmail/evccssj/
> 
> Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with
> KMail privacy policy.
Comment 45 Nate Graham 2019-08-16 16:29:48 UTC
As I understand it, there is no bug in KMail that needs fixing; rather, Google needs to unblock KMail.
Comment 46 Dirk Tombaugh 2019-08-16 18:52:06 UTC
The work-around (setting the auth method to plain) will only work if you also turn on the "less secure app" use in Google settings. Otherwise it will not authenticate.
Comment 47 Nate Graham 2019-08-16 19:03:22 UTC
Right, that's basically Google trying to get people to use only email clients they pre-approve (obviously their own is on the "we've verified that it's secure" list).

KMail isn't the only mail client to experience this issue. I went through the same thing with my mother-in-law's Apple Mail app a month or so ago; new account setup failed in exactly the same way, and the workaround was exactly the same; apparently Google demoted them too. After a few weeks Apple mail somehow got back on the approved list and setup with GMail was easy again.

Unfortunately KDE lacks the size and market power of other email client publishers. This may be something we need to escalate to the KDE e.V. I'll see what I can do.
Comment 48 matkaz1003 2019-08-16 21:21:40 UTC
(In reply to Dirk Tombaugh from comment #46)
> The work-around (setting the auth method to plain) will only work if you
> also turn on the "less secure app" use in Google settings. Otherwise it will
> not authenticate.

Page https://myaccount.google.com/lesssecureapps complains that I can't turn on "less secure app" when I have 2FA on. So this work-around involves losing some security.
Comment 49 Dennis Schridde 2019-08-17 08:28:28 UTC
Could all the people who complain so loudly here please contact Google support on the matter?  Maybe that helps them to realise that we're not talking about only 1 or 2 users here, but they are actually loosing business.  And sometimes public shaming of a company on Twitter or similar and spreading the news through the right channels helps them to understand that they are also damaging their reputation.

(In reply to matkaz1003 from comment #48)
> Page https://myaccount.google.com/lesssecureapps complains that I can't turn
> on "less secure app" when I have 2FA on. So this work-around involves losing
> some security.

Thanks for the info.  My organisation requires 2FA, so using the workaround is not possible at all.
Comment 50 Daniel Vrátil 2019-08-18 13:52:00 UTC
There's nothing to complain about, Google has some requirements, we have to fulfill them if we want to integrate with their services. At some point they found out we do not comply with their requirement, sent us a warning, but I did not have time and energy to act on it, so they blocked new logins.

I've now did the necessary changes and filed a request to have the login enabled again.
Comment 51 Sebastian 2019-08-18 14:22:33 UTC
Hi Daniel,

many thanks for taking care.

I am sorry for my clear words now but I hope my statements aren't too hurtful.

If you defined yourself as responsible maintainer for the KDE PIM - Goggle interface, the statement not having time to take care is frightening. Many people using this piece of KDE software trusting that someone is taking care. If you are no longer willing to support this topic someone else should be assigned as responsible person. However, I can understand your frustration with Google's policies but this should not lead to a situation as we are facing it right now.

Thanks again,
Sebastian
Comment 52 Daniel Vrátil 2019-08-18 14:59:16 UTC
I understand that. The KDE e.V. board has full access to the API keys on Google Cloud Console, so in the worst case they can handle this themselves or grant access to another member of the community.

Historically, I've been taking care of this because I've initially implemented the Google integration and thus I have access to the API keys as well. Usually when some action needs to be taken the Board asks me to handle it. Lately I've been a bit busy, so I wasn't able to act soon enough. Hopefully this was the last action that had to be taken for a long while again :)
Comment 53 Nicholas Sushkin 2019-08-20 15:45:50 UTC
(In reply to Daniel Vrátil from comment #50)
> I've now did the necessary changes and filed a request to have the login
> enabled again.

Hi, Daniel,

Are you expecting that Google will notify when your request has been processed?

I am still seeing "Sign in with Google temporarily disabled for this app" when Akonadi is trying to log into my MFA enabled GMail account.

Thanks
Comment 54 Brendon Higgins 2019-08-20 16:30:52 UTC
For the record (because Daniel's blog post claims otherwise), existing users can indeed be affected by this: I've had two GMail accounts accessed from three serparate machines all start refusing logins over the last few weeks, at different times. It seems like some kind of expiry happens, at which point logins start failing. PLAIN works for me, fortunately.

Feels like Google's really skirting anticompetitive/antitrust territory here. But maybe I'd have a different opinion given a bit more transparency on what they were actually asking for. Either way, thanks for going to bat for us, Daniel!
Comment 55 Dennis Schridde 2019-08-20 20:32:20 UTC
(In reply to Brendon Higgins from comment #54)
> For the record (because Daniel's blog post claims otherwise), existing users
> [...]

In case someone else also wonders what blog post Brendon talks about: https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
Comment 56 Nick 2019-08-21 03:15:16 UTC
(In reply to Brendon Higgins from comment #54)
> For the record (because Daniel's blog post claims otherwise), existing users
> can indeed be affected by this: I've had two GMail accounts accessed from
> three serparate machines all start refusing logins over the last few weeks,
> at different times. It seems like some kind of expiry happens, at which
> point logins start failing. PLAIN works for me, fortunately.
> 
> Feels like Google's really skirting anticompetitive/antitrust territory
> here. But maybe I'd have a different opinion given a bit more transparency
> on what they were actually asking for. Either way, thanks for going to bat
> for us, Daniel!

I can also confirm that existing accounts definitely can be affected. Mine has been configured for a long time and only about 3 weeks ago it started denying me access. I was able to switch to PLAIN authentication using an app specific password though.
Comment 57 Andras 2019-08-21 03:30:32 UTC
What plain authentication you guys are talking about? It's only for outgoing setup, incoming has to be configured in a way it's asked by Google anyway and basically that's where this problem is happening at least for me. I have a bunch, around 10 account setup in the right way in Kontact, I have 2 step auth.. so there is no option to set less secure app in Google account but in that case it won't be necessary in theory. It doesn't work for me either, same message appears for all of my account so I just wait.
Comment 58 Kishore Gopalakrishnan 2019-08-21 03:38:16 UTC
(In reply to Andras from comment #57)
> What plain authentication you guys are talking about? It's only for outgoing
> setup, incoming has to be configured in a way it's asked by Google anyway
> and basically that's where this problem is happening at least for me. I have
> a bunch, around 10 account setup in the right way in Kontact, I have 2 step
> auth.. so there is no option to set less secure app in Google account but in
> that case it won't be necessary in theory. It doesn't work for me either,
> same message appears for all of my account so I just wait.

You can do the same for incoming mail by going to the 'connection settings' section of the 'advanced' tab in the dialog that opens when you click 'modify' on an incoming account.
Comment 59 Andras 2019-08-21 03:46:08 UTC
(In reply to Kishore Gopalakrishnan from comment #58)
Oh my I just didn't noticed this cuz so obvious I'd love to use Google's supervision for login lol. Anyways thanks it works for me. Probably I've to use this option for now hm.
Also correction, I meant it's not possible to turn on less secure app when there is 2 step verification is used and in this case Google gives the option for app password what should work for less secure apps too, well it doesn't work either. I used my accounts in Kontact with app pw for years and now I had to reconfigure Akonandi for whatever misbehaving after some upgrade and this message just started appearing for all of my setup. Anyways, I hope it'll be solved somehow soon.
Comment 60 Christophe Marin 2019-08-24 14:53:46 UTC
*** Bug 411248 has been marked as a duplicate of this bug. ***
Comment 61 bwl 2019-09-02 12:10:11 UTC
Any further update on this? Down for 6 months now !
Comment 62 Dennis Schridde 2019-09-16 07:23:40 UTC
(In reply to Daniel Vrátil from comment #50)
> I've now did the necessary changes and filed a request to have the login
> enabled again.

Hi Daniel!

Do you have news from Google?  Was the information about the access / permissions Akonadi requests you provided to them enough?
Comment 63 Billy Nix 2019-10-03 00:54:04 UTC
Same problem on Kubuntu 19.04; Might this problem get fixed in 19.10?
KMail 5.10.3
KDE Plasma 5.15.4
KDE Frameworks 5.56.0
Qt 5.12.2
Comment 64 Laurent Montel 2019-10-12 10:08:14 UTC
*** Bug 412873 has been marked as a duplicate of this bug. ***
Comment 65 David 2019-10-12 10:30:16 UTC
Hi everybody, 
I'd like to confirm (should this help anyone else) I've been able to set up a Gmail account by using PLAIN authentication and a password app from Google Security Settings. 
Just setup the Gmail account inside Kmail normally, double check it does not work, then manually change server to imap.gmail.com, set the password as above said, change server settings to SSL-TLS port 993 auth PLAIN.
Worked for me.
Comment 66 wozny.piotr 2019-10-16 14:07:54 UTC
At Kubuntu 18.04 with backports Kontact 5.7.3

I am able to generate app specific password via google account, but switching to plane is not possible. 

Whenever i put imap.gmail.com as imap server address, the password option get gray with no possibility to set password. 

BTW There are only 2 places in Kontact I can find plain authentication: smtp settings, which I believe is not the one to change, but in imap settings there is only Sieve settings have this option. Is this the place to change to plain? anyway this is also greyed-out when gmail is imap server.

Could somebody please produce step by step instructions for this workaround so that more people like me - not being power users could work with gmail accounts / calendars / contacts?

have a nice day
Piotr
Comment 67 PK 2019-10-16 14:34:06 UTC
Created attachment 123235 [details]
kmail settings

I managed to get kmail going by walking the road that leads to the failure message of Google but stil saying "create account" in kmail.
After that when you go to the kmail settings there is (in my case) one gmail-item under "receive" (ontvangen) and one gmail item under "send" (verzenden). By dubbel-clicking on those items you can open them and edit them. There you can fil in the following:

receive...

- Imap server: imap.gmail.com
connection settings
- SSL/TLS
- 993
- PLAIN

send...
- smtp.googlemail of gmail.com
connection settings
- starttls
- 587
- PLAIN
(of topic - this is one thing I really like about Evolution Mail (gnome): you only have to fill in your Google credentials ONE TIME in the system settings (on line accounts) and calendar, contacts and email work! Oh how I wish that the kontact pim suite would get this!)
Comment 68 David 2019-10-16 15:04:27 UTC
(In reply to wozny.piotr from comment #66)
> At Kubuntu 18.04 with backports Kontact 5.7.3
> 
> I am able to generate app specific password via google account, but
> switching to plane is not possible. 
> 
> Whenever i put imap.gmail.com as imap server address, the password option
> get gray with no possibility to set password. 
> 
> BTW There are only 2 places in Kontact I can find plain authentication: smtp
> settings, which I believe is not the one to change, but in imap settings
> there is only Sieve settings have this option. Is this the place to change
> to plain? anyway this is also greyed-out when gmail is imap server.
> 
> Could somebody please produce step by step instructions for this workaround
> so that more people like me - not being power users could work with gmail
> accounts / calendars / contacts?
> 
> have a nice day
> Piotr

Just as comment 67 outlined, what I meant with "create the gmail account normally" was to create just as if the 2-factor auth worked. It will fail to complete as previously said, but then you can go in the settings and modify them manually.
Comment 69 Dennis Schridde 2019-10-16 15:25:39 UTC
(In reply to Daniel Vrátil from comment #50)
> I've now did the necessary changes and filed a request to have the login
> enabled again.

Hello Daniel!  Did you hear anything from Google in the last two months?  Do they need any more information?  Is there anything anyone can help you with?
Comment 70 Dirk Davidis 2019-10-24 08:05:37 UTC
Hi Daniel,
Hi Guys,

it is now nearly 6 month + that this feature of KDE Kontact is deactivated. So for me it is not possible to use Kontact anymore. I was there for moving completly from Gnome to KDE. So i use "Franz" to access my mails on KDE. I think it should been resolved now. If not possible then the Team should deactivate oauth2 authentication for Google in KDE Kontact.
Comment 71 David 2019-10-24 09:19:28 UTC
(In reply to Dirk Davidis from comment #70)
> Hi Daniel,
> Hi Guys,
> 
> it is now nearly 6 month + that this feature of KDE Kontact is deactivated.
> So for me it is not possible to use Kontact anymore. I was there for moving
> completly from Gnome to KDE. So i use "Franz" to access my mails on KDE. I
> think it should been resolved now. If not possible then the Team should
> deactivate oauth2 authentication for Google in KDE Kontact.

I'd say also, since this looks to me more of a legal than software issue, shall we (users) do anything/complain everywhere, just ask us. I'm personally keen in using Kmail since it's a great client - I think others here also are, and would surely participate to a group complain to Google or anything similar. 
Hadn't it ever worked I'd be like "ok, never mind", but it did. It's unacceptable.
Comment 72 Wolfgang Bauer 2019-10-27 16:02:31 UTC
*** Bug 413472 has been marked as a duplicate of this bug. ***
Comment 73 Dirk Davidis 2019-11-11 11:55:07 UTC
Hi all,

there is no update since weeks on this bug/issue. it seems no high priority as far as i can see. no answer to our questions is an answer ;-). it is sad to see that gmail and kontact with oauth2 comes unusable in KDE .... . it would be glad when someone from kde can tell us if this issue will be solved or not.
Comment 74 Hans-Peter Jansen 2019-11-11 16:41:43 UTC
Well, it seems, that the relationship to google is lacking in general.

Here's an assortment of my own findings:
https://bugs.kde.org/show_bug.cgi?id=414010, 
https://bugs.kde.org/show_bug.cgi?id=410936
Comment 75 Tom Chiverton 2019-11-12 21:49:49 UTC
Workaround doesn't work in Kmail v5.7.3 because both password and connection settings (to set to "plain") are disabled.
Even for a freshly created IMAP connection.
Something in KDE is disabling these because the email is @gmail ?
Comment 76 Tom Chiverton 2019-11-12 21:56:12 UTC
Yup, as soon as you set the IMAP server to imap.gmail.com you can see the password field goes disabled and the advanced connection settings are disabled and "gmail" type is forced.
This "helpful" would seem easy to undo, and then at least there would then be a way to connect KMail to Gmail again, because right now the feature is dead (and has been for months ?!?).
Comment 77 Tom Chiverton 2019-11-12 22:09:33 UTC
Can't even work around this by using Akonadi Console to ('configure remote') set the Authentication to "1" instead of "9" because it's reset shortly after Kmail starts, and you get the popup of doom from Google again :(
Comment 78 Dirk Davidis 2019-11-12 22:15:56 UTC
For me just oauth2 will work in my GSuite Account so all other workarounds dont. So i am still waiting that this issue will be sorted out after mmmmh more then half a year.
Comment 79 David 2019-11-13 09:57:10 UTC
I suggest we users try to make a more appropriate complaint. A Google group maybe? Anything google may take more care of than KDE bugtracking system? I don't know, I'm asking anyone with more experience.
It's not exactly fair it all seems like it's KDE's fault whereas it's Google unreasonably f*cking us. Moreover it used to work initially and pretty soon as the strong auth methods made their way into G accounts, so why now kmail has suddenly become unsecure to them?
Comment 80 Wolfgang Bauer 2019-11-13 14:34:11 UTC
(In reply to Tom Chiverton from comment #75)
> Workaround doesn't work in Kmail v5.7.3 because both password and connection
> settings (to set to "plain") are disabled.
> Even for a freshly created IMAP connection.
> Something in KDE is disabling these because the email is @gmail ?

Try to use imap.googlemail.com as server, see https://bugs.kde.org/show_bug.cgi?id=410700#c3
Comment 81 Tom Chiverton 2019-11-13 20:33:14 UTC
That works, nice.
Comment 82 bwl 2019-11-14 09:44:02 UTC
Are we going to throw a party for this poor little bug when it is a year old ?
What a complete shambles.  Who owns this problem and what is being done to progress it?  The lack of concrete information is shameful.  Can someone please take responsibility for this and provide an update. No more workarounds or blame shifting.  Be professional.
Comment 83 Rex Dieter 2019-11-14 14:21:40 UTC
FYI, for those wanting an update, the last status update was comment #50 , and now the onus is on google's side to act on it.
Comment 84 bwl 2019-11-14 17:55:39 UTC
So comment 50 by Daniel on 18.08.2019 Indicated a request to have the login enabled again was submitted  Since then . . . . What?  Please understand this is not aimed at Daniel.  He stated that he is too busy,  but also that the KDE e.V.board has access to the API keys and can delegate this task to others if Daniel has no time.  Therefore we need to know when was the last contact with Google and when can we expect a response.  The KDE e.V. board need to wake up and start handling this properly and professionally.  No single point of failure.
Comment 85 Dirk Tombaugh 2019-11-14 18:01:41 UTC
Right now I would say the single point of failure is on Google. KDE (Daniel and everyone else) can only do so much. They don't have the pull of say Microsoft. It is frustrating, but instead of commenting here about it being a KDE issue, we need to start complaining to Google (if that is even possible).
Comment 86 Michael 2019-12-10 21:02:02 UTC
I notice this bug report is assigned to Akonadi. But KAccounts also suffers from the same issue.
Should we perhaps create another bug report about it, or would that be a duplicate ?
Comment 87 davidblunkett 2019-12-12 12:53:10 UTC
Yet another comment moaning about the stale nature of this bug follows:

I really don't understand why this has been allowed to fester for so long by the KDE developers.  A capable email system is an essential component of a desktop system and that means working with key email providers (which gmail is). I realise there is an inelegant kludge to get around this problem but it comes at a cost of constant whinging from google about security and the kludge is not a fit way for regular lay users to use email.

Leaving this to fester is sticking two fingers up to friendly computing and saying to non-technically savvy users "find a better OS".  When they find a better OS, the critical mass for KDE will **** off and it will wither.  That's a shame because I quite like KDE.

This rant comes from me having to fix yet another lay users' kmail, spend an hour arsing around with kmail and akonadi, putting up with gmail's whinging etc. I think next time the answer will be a more cared for desktop. Lay users cannot be arsed with this and they will go elsewhere. Perhaps we shouldn't care but it seems sad if we don't.

Replies that say "it's in google's hands" don't count, the rest of the world seems to be able to work it.
Comment 88 Nate Graham 2019-12-12 13:58:55 UTC
You don't have to stop using all KDE software; you can just swap KMail out for Thunderbird for example, and it works great. That's what I had to do. :(
Comment 89 Mark Stanton 2019-12-12 15:17:44 UTC
This still doesn't work? Wow, I (too) reported this months ago.

At risk of another "me too" reply, yes, me too.

Evolution works just fine under KDE, with GoogleMail, and has address book and calendar, as the K-suite has, and doesn't have Akonadi, which is also a great plus.
Comment 90 Eike Hein 2019-12-13 11:09:37 UTC
With my board hat on: We'll look into what we can do to push this forward. Daniel, could you send us info on the ticket you raised with Google so we may take it up for you if you're too busy?

Note we'll push for getting this process and the access credentials documented with the sysadmin team, to avoid things getting stuck in the future. If you need to escalate to us it usually already went wrong ideal-process-wise :-)
Comment 91 Hans-Peter Jansen 2019-12-13 16:08:14 UTC
Dear audience,

Regarding this issue, simple workarounds exist, follow https://bugs.kde.org/show_bug.cgi?id=410700 please.

In general, it would be nice to not spread FUD about Akonadi/Kmail. As a long time heavy user (once started with KDE 2), I can confirm, that Akonadi/Kmail is one of the most powerful MUAs available today. If you have high demands, you need to tweak the defaults a bit (e.g. by using PostgreSQL) and provide enough resources. But be assured, that the only MUA that comes close, Thunderbird, start to suck rocks, if you throw enough mails on it. My biggest mailbox is about 140 GB(!), and I have a dozen accounts to manage.. Kmail starts in less than 60 seconds, with a full scan on it! Try this with Thunderbird. 

Sure, issues exist. An currently, the google integration sucks in several ways.
But basically, it is good enough to be used on a daily base.
Comment 92 Tom Chiverton 2019-12-14 11:47:01 UTC
There is no FUD.

KDE should pull the GMail integration from KMail, instead setting up a pure IMAP link, unless or until they win the fight with Google.

This would be an excellent interim solution that would lead to frustrated users (see above).
Comment 93 Colin MacLean 2019-12-14 21:08:18 UTC
If mail was the only feature I cared about, I would just use IMAP and not really care about this issue. However, I need to plugin for Google Calendar support. There is no good read/write workaround for that which I know of.
Comment 94 Std cerr 2019-12-15 00:08:00 UTC
(In reply to Tom Chiverton from comment #92)
> There is no FUD.
> 
> KDE should pull the GMail integration from KMail, instead setting up a pure
> IMAP link, unless or until they win the fight with Google.
> 
> This would be an excellent interim solution that would lead to frustrated
> users (see above).

Interesting that it is such an issue for this project. I by now have moved to Thunderbird and email (IMAP) & calendar integration works like a charm. 
For the calendar to synchronize in bi-directionally, you need to grab and install this Addon: https://addons.thunderbird.net/en-US/thunderbird/addon/provider-for-google-calendar/ I've got thte information from this video: https://www.youtube.com/watch?v=wbN9hHGNwIM
Comment 95 Nicholas Sushkin 2019-12-17 06:33:14 UTC
Google is disabling password access altogether

I got the following email yesterday:

----------------
From:	The G Suite Team <gsuite-noreply@google.com>

Beginning June 15, 2020, non-Google apps that use only a password to access  
Google accounts will no longer be supported.

Starting February 15, 2021, G Suite accounts will only allow access to apps  
using OAuth. Password-based access will no longer be supported.

Dear Administrator,

We're constantly working to improve the security of your organization's  
Google accounts. As part of this effort, and in consideration of the  
current threat landscape, we'll be turning off access to less secure apps  
(LSA) — non-Google apps that can access your Google account with only a  
username and password, without requiring any additional verification steps.  
Access through only a username and password makes your account more  
vulnerable to hijacking attempts. Moving forward, only apps that support a  
more modern and secure access method called OAuth will be able to access  
your G Suite account.

Access to LSAs will be turned off in two stages:


June 15, 2020 - Users who try to connect to an LSA for the first time will  
no longer be able to do so. This includes third-party apps that allow  
password-only access to Google calendars, contacts, and email via protocols  
such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to  
this date will be able to continue using them until usage of all LSAs is  
turned off.
February 15, 2021 - Access to LSAs will be turned off for all G Suite  
accounts.

What do I need to do?

To continue using a specific app with your G Suite accounts, users in your  
organization must switch to a more secure type of access called OAuth. This  
connection method allows apps to access accounts with a digital key instead  
of requiring a user to reveal their username and password. We recommend  
that you share the user instructions (included below) with individuals in  
your organization to help them make the necessary changes. Alternatively,  
if your organization is using custom tools, you can ask the developer of  
the tool to update it to use OAuth. Developer instructions are also  
included below.

MDM configuration

If your organization uses a mobile device management (MDM) provider to  
configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles,  
these services will be phased out according to the timeline below:


June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync  
(Google Sync) will no longer work for new users.
February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange  
ActiveSync (Google Sync) will no longer work for existing users. Admins  
will need to push a Google Account using their MDM provider, which will  
re-add their Google accounts to iOS devices using OAuth.

Other less secure apps


For any other LSA, ask the developer of the app you are using to start  
supporting OAuth.
If you use other apps on iOS or MacOS that access your G Suite account  
information through only a password, most access issues can be resolved by  
removing then re-adding your account. When you add it back, make sure to  
select Google as the account type to automatically use OAuth.

Scanners and other devices

No change is required for scanners or other devices using simple mail  
transfer protocol (SMTP) or LSAs to send emails. If you replace your  
device, look for one that sends email using OAuth.

User instructions

If you are using an app that accesses your Google account with only a  
username and password, take one of the following actions to switch to a  
more secure method and continue to access your email, calendar, or  
contacts. If you do not take one of the following actions, when LSA access  
is discontinued after February 15, 2021, you will begin receiving an error  
message that your username-password combination is incorrect.

Email


If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a  
web-based version of Outlook) or Outlook 2019, both of which support OAuth  
access. Alternatively you can use G Suite Sync for Microsoft Outlook.
If you are using Thunderbird or another email client, re-add your Google  
Account and configure it to use IMAP with OAuth.
If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use  
only a password to login, you'll need to remove and re-add your account.  
When you add it back, select “sign in with Google” to automatically use  
OAuth.


Mac OS iOS


mail app view Mac OS

mail app view iOS



Calendar


If you use CalDAV to give an app or device access to your calendar, switch  
to a method that supports OAuth. We recommend the Google Calendar app  
[Web/iOS/Android] as the most secure app to use with your G Suite account.
If your G Suite account is linked to the calendar app in iOS or MacOS and  
uses only a password to login, you'll need to remove and re-add your  
account to your device. When you add it back, select “sign in with Google”  
to automatically use OAuth. Read more

Contacts


If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and  
uses only a password to login, you'll need to remove your account. When you  
add it back, select “sign in with Google” to automatically use OAuth. Read  
More
If your G Suite account is syncing contacts to any other platform or app  
via CardDAV and uses only a password to login, switch to a method that  
supports OAuth.

Note: If the app you are using does not support OAuth, you will need to  
switch to an app that offers OAuth, or ask your admin to contact the  
supplier of your app and request that they add OAuth as a way of connecting  
your Google account.

Developer instructions

To maintain compatibility with G Suite accounts, update your app to use  
OAuth 2.0 as a connection method. To get started, follow our developer  
guide on using OAuth 2.0 to access Google APIs. You can also refer to our  
guide on OAuth 2.0 for mobile & desktop apps.

How can I get help?

If you have additional questions or need assistance, please contact G Suite  
support. When you call or submit your support case, reference issue number  
145694552.

Thanks for choosing G Suite.

—The G Suite Team
Comment 96 David 2019-12-17 08:21:22 UTC
(In reply to Nicholas Sushkin from comment #95)
> Google is disabling password access altogether
> 
> I got the following email yesterday:
> 
> ----------------
> From:	The G Suite Team <gsuite-noreply@google.com>
> 
> Beginning June 15, 2020, non-Google apps that use only a password to access  
> Google accounts will no longer be supported.
> 
> Starting February 15, 2021, G Suite accounts will only allow access to apps  
> using OAuth. Password-based access will no longer be supported.
> 
> Dear Administrator,
> 
> We're constantly working to improve the security of your organization's  
> Google accounts. As part of this effort, and in consideration of the  
> current threat landscape, we'll be turning off access to less secure apps  
> (LSA) — non-Google apps that can access your Google account with only a  
> username and password, without requiring any additional verification steps.  
> Access through only a username and password makes your account more  
> vulnerable to hijacking attempts. Moving forward, only apps that support a  
> more modern and secure access method called OAuth will be able to access  
> your G Suite account.
> 
> Access to LSAs will be turned off in two stages:
> 
> 
> June 15, 2020 - Users who try to connect to an LSA for the first time will  
> no longer be able to do so. This includes third-party apps that allow  
> password-only access to Google calendars, contacts, and email via protocols  
> such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to  
> this date will be able to continue using them until usage of all LSAs is  
> turned off.
> February 15, 2021 - Access to LSAs will be turned off for all G Suite  
> accounts.
> 
> What do I need to do?
> 
> To continue using a specific app with your G Suite accounts, users in your  
> organization must switch to a more secure type of access called OAuth. This  
> connection method allows apps to access accounts with a digital key instead  
> of requiring a user to reveal their username and password. We recommend  
> that you share the user instructions (included below) with individuals in  
> your organization to help them make the necessary changes. Alternatively,  
> if your organization is using custom tools, you can ask the developer of  
> the tool to update it to use OAuth. Developer instructions are also  
> included below.
> 
> MDM configuration
> 
> If your organization uses a mobile device management (MDM) provider to  
> configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles,  
> these services will be phased out according to the timeline below:
> 
> 
> June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync  
> (Google Sync) will no longer work for new users.
> February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange  
> ActiveSync (Google Sync) will no longer work for existing users. Admins  
> will need to push a Google Account using their MDM provider, which will  
> re-add their Google accounts to iOS devices using OAuth.
> 
> Other less secure apps
> 
> 
> For any other LSA, ask the developer of the app you are using to start  
> supporting OAuth.
> If you use other apps on iOS or MacOS that access your G Suite account  
> information through only a password, most access issues can be resolved by  
> removing then re-adding your account. When you add it back, make sure to  
> select Google as the account type to automatically use OAuth.
> 
> Scanners and other devices
> 
> No change is required for scanners or other devices using simple mail  
> transfer protocol (SMTP) or LSAs to send emails. If you replace your  
> device, look for one that sends email using OAuth.
> 
> User instructions
> 
> If you are using an app that accesses your Google account with only a  
> username and password, take one of the following actions to switch to a  
> more secure method and continue to access your email, calendar, or  
> contacts. If you do not take one of the following actions, when LSA access  
> is discontinued after February 15, 2021, you will begin receiving an error  
> message that your username-password combination is incorrect.
> 
> Email
> 
> 
> If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a  
> web-based version of Outlook) or Outlook 2019, both of which support OAuth  
> access. Alternatively you can use G Suite Sync for Microsoft Outlook.
> If you are using Thunderbird or another email client, re-add your Google  
> Account and configure it to use IMAP with OAuth.
> If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use  
> only a password to login, you'll need to remove and re-add your account.  
> When you add it back, select “sign in with Google” to automatically use  
> OAuth.
> 
> 
> Mac OS iOS
> 
> 
> mail app view Mac OS
> 
> mail app view iOS
> 
> 
> 
> Calendar
> 
> 
> If you use CalDAV to give an app or device access to your calendar, switch  
> to a method that supports OAuth. We recommend the Google Calendar app  
> [Web/iOS/Android] as the most secure app to use with your G Suite account.
> If your G Suite account is linked to the calendar app in iOS or MacOS and  
> uses only a password to login, you'll need to remove and re-add your  
> account to your device. When you add it back, select “sign in with Google”  
> to automatically use OAuth. Read more
> 
> Contacts
> 
> 
> If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and  
> uses only a password to login, you'll need to remove your account. When you  
> add it back, select “sign in with Google” to automatically use OAuth. Read  
> More
> If your G Suite account is syncing contacts to any other platform or app  
> via CardDAV and uses only a password to login, switch to a method that  
> supports OAuth.
> 
> Note: If the app you are using does not support OAuth, you will need to  
> switch to an app that offers OAuth, or ask your admin to contact the  
> supplier of your app and request that they add OAuth as a way of connecting  
> your Google account.
> 
> Developer instructions
> 
> To maintain compatibility with G Suite accounts, update your app to use  
> OAuth 2.0 as a connection method. To get started, follow our developer  
> guide on using OAuth 2.0 to access Google APIs. You can also refer to our  
> guide on OAuth 2.0 for mobile & desktop apps.
> 
> How can I get help?
> 
> If you have additional questions or need assistance, please contact G Suite  
> support. When you call or submit your support case, reference issue number  
> 145694552.
> 
> Thanks for choosing G Suite.
> 
> —The G Suite Team

This all is starting to sound like a joke to me. Timing was great.
Comment 97 Aaron Williams 2019-12-17 10:13:34 UTC
Starting today I can no longer even send email via KMail. Can we please get Google to re-authorize KMail?
Comment 98 Alexander Potashev 2019-12-17 11:42:33 UTC
I have a idea for workaround.


For the context, read carefully: https://developers.google.com/gmail/api/auth/about-auth
It mentions verification of *public* applications.

Google permits usage of Google APIs without app verification unless you application is published. For example, I use my own little script for automated processing of some specific types of emails that I receive daily on my Gmail address - Google doesn't care about verification in this case because it's my personal app.

So, what if we let KMail users create their "applications" at Google API Console [1] and force KMail to use the new app token instead of the KMail's official token?
This sounds like an abuse Google APIs at first, but we can view this as if the user forked KMail and created a new app token for it since their "forked" version of KMail is now personal application.


To make this workaround easy to employ, we need to un-hardcode the Akonadi's Google app ID and put it in a configuration file. At the moment it is hardcoded as https://github.com/KDE/kdepim-runtime/search?q=554041944266 - in these two files:
 - resources/google/common/googlesettings.cpp
 - resources/imap/gmailpasswordrequester.cpp


[1] https://console.developers.google.com/
Comment 99 Wolfgang Bauer 2019-12-17 11:48:02 UTC
*** Bug 415280 has been marked as a duplicate of this bug. ***
Comment 100 David Bate 2019-12-29 16:34:41 UTC
Looks like this has now gone across the KDE platform. After re-installing KDE/Tumbleweed, I can no longer sign into google via the system settings > online accounts nor via dolphin > networks.
Comment 101 David Sijbesma 2019-12-29 16:48:13 UTC
   Agree, same here. This had me to unfortunately shift towards the gnome
   desktop environment.
   Hope this will be addressed really soon.
   Cheers, David



   -------- Original message --------
   From: David Bate <bugzilla_noreply@kde.org>
   Date: Sun, 29 Dec 2019, 17:34
   To: dsijbesma@gmail.com
   Subject: [Akonadi] [Bug 404990] Sign in with Google temporarily
   disabled for this app

     https://bugs.kde.org/show_bug.cgi?id=404990

     --- Comment #100 from David Bate <va3dbj@outlook.com> ---
     Looks like this has now gone across the KDE platform. After
     re-installing
     KDE/Tumbleweed, I can no longer sign into google via the system
     settings >
     online accounts nor via dolphin > networks.

     --
     You are receiving this mail because:
     You are on the CC list for the bug.
Comment 102 David Sijbesma 2020-01-02 20:36:50 UTC
Hi everybody,

first of all, Happy New Year!

I'm pretty curious, is there any idea about an eta of a fixed version?
Next to that, is ther anything I can help with?

Cheers, David

On Sun, 2019-12-29 at 16:34 +0000, David Bate wrote:
> https://bugs.kde.org/show_bug.cgi?id=404990
> 
> --- Comment #100 from David Bate <va3dbj@outlook.com> ---
> Looks like this has now gone across the KDE platform. After re-
> installing
> KDE/Tumbleweed, I can no longer sign into google via the system
> settings >
> online accounts nor via dolphin > networks.
>
Comment 103 Poloi 2020-01-02 20:55:36 UTC
(In reply to Daniel Vrátil from comment #50)
> I've now did the necessary changes and filed a request to have the login
> enabled again.

Best of luck in 2020, everyone!

Indeed, is there any news on the progress of the request you filed, Daniel? Since this issue is now relevant not only to KMail but the whole K-stack, it seems a bit odd for Google to ~ignore~ process the request for so long.

Sorry if I've missed it, but does this request cover just KMail or will KOrganizer get fixed as well as a result?
Comment 104 Dennis Schridde 2020-01-14 07:35:00 UTC
I received a response from Adriaan de Groot <groot@kde.org>:

> Please see https://euroquis.nl/kde/2020/01/13/google.html .. there is 
progress, although Google's review of KMail's use of access to GMail is still 
pending.

tl;dr: The contacts and calendar issues should be fixed by the upcoming February 2020 update of KDE Apps, but the email problem is still work in progress.
Comment 105 David Bate 2020-01-14 16:03:38 UTC
I am able to get back in and now everything is working as it was before the total shutout.  Calendar/Contact are now working and email is working again via the "Plain" setting.  The glitch at the moment is the files access. I went through the motions via the KDE settings, online accounts, it went through the approval and a window came up saying the Google files access is now available and now (Google) is now listed.

But now when i click on Google in dolphin, a New Account icon is showing, not the actual file area. I click on that, and it open the Online Accounts, with (Google) already there. Kinda takes you through a bit of a repeated cycle. You never do actually get to your files on Google, even though the earlier process said it was completed.  Hmm..
Comment 106 Dennis Schridde 2020-01-14 16:32:35 UTC
I confirm: On Fedora 31 Google Contacts, Calendars and Tasks work again in Akonadi (as expected from Adriaan's reply), while GMail does not (which is also as expected).
Comment 107 Dennis Schridde 2020-01-18 09:12:48 UTC
In case you want to know more of the background, there is an article in German magazine iX and Heise Online.  In the last paragraph, the KDE PIM issue is being mentioned.

https://www.heise.de/ix/meldung/Mailbox-org-Google-sperrt-unsichere-Dritte-von-Kalender-aus-4640540.html
Comment 108 Unknown 2020-01-25 13:10:45 UTC
Unfortunately GMail is still blocked, but Evolution works.
It's a shame that you can't use kmail under KDE but have to switch to GTK

Greeting
Comment 109 Hans-Peter Jansen 2020-01-25 13:28:28 UTC
May I kindly ask you to read https://bugs.kde.org/show_bug.cgi?id=404990#c91

Thanks
Comment 110 davidblunkett 2020-02-04 18:09:04 UTC
Are we having a birthday party for this bug next month?
Comment 111 David 2020-02-04 19:14:25 UTC
(In reply to davidblunkett from comment #110)
> Are we having a birthday party for this bug next month?

Definitely the way to go
Comment 112 la_iscla 2020-02-08 18:30:20 UTC
Funnily enough, I managed to declare my Google accounts in the "Online accounts". This seems to handle the OAuth2 process better (but that does not translate into KMail being set up).
Perhaps as a workaround there's a way to copy the credentials stored in .config/libaccounts-glib/accounts.db into akonadi's wallet entries
Comment 113 Said Bakr 2020-02-11 19:39:56 UTC
The issue is also found for me at Kubuntu 18.04 when using Kio Gdrive from Dolphin.
Comment 114 Wolfgang Bauer 2020-02-12 06:50:48 UTC
(In reply to Said Bakr from comment #113)
> The issue is also found for me at Kubuntu 18.04 when using Kio Gdrive from
> Dolphin.
That's fixed already (in kaccounts-providers 19.12.2):
https://cgit.kde.org/kaccounts-providers.git/commit/?id=0a71da4e3caae0defe200a85954fc7e2012010c1

But that has nothing to do with Akonadi or its IMAP resource.
Comment 115 davidblunkett 2020-03-02 20:39:21 UTC
*** Removed by KDE Sysadmin ***
Comment 116 Henrique Leal 2020-03-04 09:00:03 UTC
*** Removed by KDE Sysadmin ***

Really unfair :'(
Comment 117 davidblunkett 2020-03-04 14:55:55 UTC
Well, this bug is one year old now and as youthful as it has ever been - I suspect it might have the same longevity as the ever youthful "Multiple merge candidates, aborting" bug.
Comment 118 Christophe Marin 2020-03-04 17:58:11 UTC
That's not a reason for spamming dozens of users with your useless comment.

Unless you have valuable input for this bug report (spoiler: you don't), please avoid commenting.
Comment 119 David Sijbesma 2020-03-04 18:03:24 UTC
Created attachment 126602 [details]
attachment-13124-0.html

All,

Any news on this, what's the current status? As mentioned before, I'm happy
to contribute to speed up the process. Please let me know!

Cheers, David

On Wed, Mar 4, 2020, 18:58 Christophe Giboudeaux <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=404990
>
> --- Comment #118 from Christophe Giboudeaux <christophe@krop.fr> ---
> That's not a reason for spamming dozens of users with your useless comment.
>
> Unless you have valuable input for this bug report (spoiler: you don't),
> please
> avoid commenting.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 120 Christophe Marin 2020-04-10 20:58:16 UTC
*** Bug 419913 has been marked as a duplicate of this bug. ***
Comment 121 Ruben Kelevra 2020-04-23 13:34:10 UTC
So, this bug is still ongoing, for more than one year. 

When Kontact can't register an account with the login page, it should at least point out to a help page which contains more information about that.

Apart from that:

GMail is one of the largest providers in the world and KDE one of the largest IDEs out there - it should be possible to find a solution for the users!
Comment 122 Daniel Vrátil 2020-05-12 06:03:13 UTC
Google has approved KMail access to Gmail via Googla Sign-in today, so it should work again. Should you still see some errors, please let us know.

https://www.reddit.com/r/kde/comments/gi5bol/kmailkontact_oauth_signin_with_gmail_enabled_again/
Comment 123 Aldo Latino 2020-05-12 16:47:57 UTC
Thank you, it works! :)
Comment 124 PK 2020-05-12 17:20:55 UTC
To my regret I must say that on my system it doesn't work (completely).
- to start I tried configuring kmail using the new tool in the systemsettings and that didn't work at all
- the I used the good old account wizzard of kmail itself and that went fine. Only when I, some time later, tried to send an email, it went wrong. 
I was informed that to send an email I had to use a app-specific password or so.
Comment 125 David Sijbesma 2020-05-12 17:30:17 UTC
It works on my side. OpenSUSE Tubleweed updated to the latest patches. 
So really glad. 

Thanks, David

On Tuesday, May 12, 2020 7:20:55 PM CEST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=404990
> 
> --- Comment #124 from PK <pieterkristensen@gmail.com> ---
> To my regret I must say that on my system it doesn't work (completely).
> - to start I tried configuring kmail using the new tool in the
> systemsettings and that didn't work at all
> - the I used the good old account wizzard of kmail itself and that went
> fine. Only when I, some time later, tried to send an email, it went wrong.
> I was informed that to send an email I had to use a app-specific password
> or so.
Comment 126 Aldo Latino 2020-05-12 18:55:09 UTC
(In reply to PK from comment #124)
> To my regret I must say that on my system it doesn't work (completely).
> - to start I tried configuring kmail using the new tool in the
> systemsettings and that didn't work at all
> - the I used the good old account wizzard of kmail itself and that went
> fine. Only when I, some time later, tried to send an email, it went wrong. 
> I was informed that to send an email I had to use a app-specific password or
> so.

I resolved updating the connection settings. Go to Settings > Configure Kmail > Sending tab [1] > Select your Gmail account, then Modify.

General tab:
- Outgoing email: smtp.gmail.com
- Activate "The server requires authentication"
- Username: your email address
- Password: leave it empty
- Save SMTP password: unchecked

Advanced tab:
- Cipher: STARTTLS
- Port: 587
- Authentication: XOAUTH2
Leave all other fields empty and the checkboxes deactivated.

With these settings my Kmail works as expected when sending emails.

[1] I use Kmail in Italian, so I don't know the exact strings used.
Comment 127 PK 2020-05-12 19:12:40 UTC
I followed Aldo Latino of comment 126 and it worked flawlessly! Thank you so much! I hope others don't have this problem.
But thank you!
Comment 128 Jacob S. 2020-05-13 00:05:22 UTC
I received the news stating this had been addressed, it didn't work either. I simply waited for a few hours, and it worked.
Comment 129 Vishnu 2020-05-16 08:01:35 UTC
Sending also works, following advice by Aldo.

But not very well. I am having to restart akonadi every now-and-then, because other wise, the email never leaves the local outbox.

It looks like the restart requests a new [SASL-XOAUTH2] token. Am I doing something wrong? Is this a separate bug report?
Comment 130 Aldo Latino 2020-05-16 10:04:54 UTC
(In reply to Vishnu from comment #129)
> Sending also works, following advice by Aldo.

Okay.

> But not very well. I am having to restart akonadi every now-and-then,
> because other wise, the email never leaves the local outbox.

I do not send email so often, so today I'm seeing that my emails don't leave the outbox.

> It looks like the restart requests a new [SASL-XOAUTH2] token. Am I doing
> something wrong? Is this a separate bug report?

I confirm. Restarting Akonadi (akonadictl restart) "solves" the issue, but perhaps temporarily. I will check in the next days.
Comment 131 Aldo Latino 2020-05-16 13:56:18 UTC
(In reply to Aldo Latino from comment #130)
> [cut] I confirm. Restarting Akonadi (akonadictl restart) "solves" the issue, but
> perhaps temporarily. I will check in the next days.

After a few hours I had to restart Akonadi to send an email.
Comment 132 Christoph Feck 2020-05-16 15:41:03 UTC
Please discuss issues unrelated to the "Sign in with Google temporarily disabled for this app" message in a separate ticket.
Comment 133 Vishnu 2020-06-17 07:16:23 UTC
Opened a report for that: https://bugs.kde.org/show_bug.cgi?id=421664