https://bugs.archlinux.org/task/32668

Are you using 2-factor authentication with Google? If you are, then it is better not to use GOA at the moment.

The problem is that in 3.6 we use CalDAV for Google Calendars, which does not work with OAuth tokens, only with passwords. Neither does GTalk, which needs OAuth2.

We have partly solved the problem for 3.8, by migrating our Google provider to use OAuth2. This takes care of GTalk, but the problem with calendars remain.

Google does have plans to support OAuth2 with CalDAV, but not sure when that will be available more widely. Or you can write and maintain a libgdata based backend for E-D-S till that happens.

This is only about Google. Facebook 2-factor authentication works.

See bug 687578 for why this used to "work" to some extent, but doesn't any more.

i'm not using 2-factor authentication with google and I have the same issue.

i'm using 2-factor authentication, but gnome concats doesn't support, so I use my generic goofle password. and thats works fine before

Ioni, what happens if you click "log in" to refresh the account?

It makes me login on google and after hitting grant access, the popup window closes and I still have the log in button with the message that the credential expired. 

Trying to set the chat available in gnome-shell, I have the authentication failed notification.

update: After opening Seahorse, I noticed that I had two goa_ entries in the keyring.

After deleting them and tried to log in to refresh the credentials, everything works as expected.

I believe is a duplicate of bug 681727

@Ivan please confirm.

No it's not working for me
I've only one goa_ entry, several evolution entries and multiple google mail enrties
I erased them all and have no luck even with relogon

However I found a way to fix, thanks @Ionut showing a path

In my GOA_ entry I edited 'password' field
So I removed my generic google password and inserted google application password, I got in my 2-factor authentication page. So it's working fine now, but it should be fixed I think ti work out of box ;)

(In reply to comment #10)

So you were using 2-factor. :-)

> However I found a way to fix, thanks @Ionut showing a path
> 
> In my GOA_ entry I edited 'password' field
> So I removed my generic google password and inserted google application
> password, I got in my 2-factor authentication page. So it's working fine now,
> but it should be fixed I think ti work out of box ;)

See comment 2 for what needs to happen for it to work out of the box.

> See comment 2 for what needs to happen for it to work out of the box.

It's not acceptable solution for me to disable 2-factor authentication, and I find a way to make it works, so it's not so hard to ask an application password. And as I said before previous version works fine. Also chromium support 2-factor authentication properly, so you can use the code from here to see how it works ;)

(In reply to comment #12)

> It's not acceptable solution for me to disable 2-factor authentication, and I

Nobody told you to do so.

> find a way to make it works, so it's not so hard to ask an application
> password.

It is hard to ask for an application password without screwing up the whole UX for everybody -- including non-2-factor users.

> And as I said before previous version works fine.

It does not. You would have known if you read through the bug that I mentioned earlier.

> Also chromium
> support 2-factor authentication properly, so you can use the code from here to
> see how it works ;-)

That is a cute smiley, but we don't need to see what Chromium does. We know what is required and what the current problems are. I already described them once, won't do it again.

You guy really should look at chromium, because it used the same api to integrate with account and the same dialog with the only difference it's enable to enter application password.

Also I see a lot of sarcasm in your way to make the gnome works properly for users, making a break a lot of things previosly works goog for me and many other people. So I think that way you realy goes to say "do not use the gnome" with in 3.8 release. So good luck

(In reply to comment #14)
> You guy really should look at chromium, because it used the same api to
> integrate with account and the same dialog with the only difference it's enable
> to enter application password.

See https://bugzilla.gnome.org/show_bug.cgi?id=686804#c8 (which depends on bug 687578).

> Also I see a lot of sarcasm in your way to make the gnome works properly for
> users, making a break a lot of things previosly works goog for me and many
> other people. So I think that way you realy goes to say "do not use the gnome"

It is easy to say things like "works for me and many other people" when you are not sitting at the receiving end of bugzilla and hearing complaints from those for whom it wasn't working well.

If you are someone who does not use 2-factor then you have to re-enter your password thrice -- once in GOA, once in EDS, once in Empathy. This sucks.

We have solved the problem for Empathy and 2-factor because we use OAuth2 tokens now. We used to use OAuth1 tokens before.

However, EDS (which uses Google Calendars via CalDAV) is still a problem. I know that Google is going to support OAuth2 over CalDAV, but the exact date is unclear. If that does not happen in time for 3.8, the other option is to write a GData based calendar backend for EDS. The Evolution developers are not too happy to write and maintain yet another vendor-specific backend (ie. GData), so maybe you can help them.

On second thoughts, maybe we should keep this bug open till this situation is resolved.

Come on man. I'm a software developer in trueconf.com company. And I'm receiving a lot of bugzilla updates every hour. I do not want to hurt you however I realy disappointed 3.6 update, that make me sit on gnome bugzilla instead of working comfortable as before. I really do not understand why the features working before stops working now. So it's not personal but professional fault to me and I'm sorry if it was too hard in text

(In reply to comment #17)
> Come on man. I'm a software developer in trueconf.com company. And I'm
> receiving a lot of bugzilla updates every hour.

My apologies if my words came across as harsh.

> instead of working comfortable as before. I really do not understand why the
> features working before stops working now. So it's not personal but
> professional fault to me and I'm sorry if it was too hard in text

To make things work smoothly for non-2-factor users we scrape the password from the web page and offer it to applications that need to work with Google services that do not use OAuth. Otherwise they have to re-enter their password in EDS and Empathy again, which sucks.

However, this breaks things for 2-factor users because they can not use the password that we offer, because we can not scrape the application specific password from the web page.

Also, GOA retries to verify that the credentials that it has for your account (ie. the OAuth token and the password in this case) are still valid. To check the password it uses the CalDAV endpoint. Since your normal password does not work in this case, and you need an application specific password it fails. This becomes an endless loop because your normal password will never work with 2-factor.

Since EDS throws a black system modal dialog at the user, it is hard for the user to enter their application specific password because it tends to be long and some people have it saved in an encrypted file on their computer. Even if we got rid of the black system modal, and replaced it with a normal dialog, things are still not as smooth as they could be. Also, that requires changes in EDS, so you will have to talk to the EDS folks.

Ideally someone has to write a GData calendar backend for EDS and things would work. But someone has to write the code and maintain it. You can be that someone.

Or we have to wait till Google makes OAuth2 support for CalDAV more widely available.

I read the comments I understand we are really waiting at this point more than anything else but I wanted to go ahead and add a confirmation of sorts anyway:

https://bugs.archlinux.org/task/32761

The part I don't understand (I'm hoping Ivan or someone can elaborate for me) is the work around mentioned in Comment 10.

Generally I consider myself fairly capable in most things 'Nix' related but some things still puzzle me at least a bit (I was raised as a windoze {don't hold it against me ;) } user but I abandoned it years ago for anything other than my work), mainly related to hidden config files (give me something I can echo or cat to and I'll be happy, just not sure where to look ATM).

Use Seahorse to look at your keyring and try to locate the entry associated with your Google account. (Hint: You can put "GOA" in the search bar to filter the view to show only things stored by GOA.)

You will see that it has a dictionary. Locate the key called "password". Replace the value associated with that key with your application specific password.

(In reply to comment #20)
> Use Seahorse to look at your keyring and try to locate the entry associated
> with your Google account. (Hint: You can put "GOA" in the search bar to filter
> the view to show only things stored by GOA.)
> 
> You will see that it has a dictionary. Locate the key called "password".
> Replace the value associated with that key with your application specific
> password.

Yes. Check the show password, you'll see a long GOA_ string. At the end you'll see your google password. If you enable 2-factor auth and reproduces a bug, you should make an application password in google account and replace your google password in seahorse with it. Logoff and login again after solves the "expiration" problem

Wonderful; that did indeed work. Thank you gentlemen for the assistance.

*** Bug 688773 has been marked as a duplicate of this bug. ***

(In reply to comment #21)
> (In reply to comment #20)
> > Use Seahorse to look at your keyring and try to locate the entry associated
> > with your Google account. (Hint: You can put "GOA" in the search bar to filter
> > the view to show only things stored by GOA.)
> > 
> > You will see that it has a dictionary. Locate the key called "password".
> > Replace the value associated with that key with your application specific
> > password.
> 
> Yes. Check the show password, you'll see a long GOA_ string. At the end you'll
> see your google password. If you enable 2-factor auth and reproduces a bug, you
> should make an application password in google account and replace your google
> password in seahorse with it. Logoff and login again after solves the
> "expiration" problem

Excellent! this solution is working perfectly at least as a temporary solution, have been looking for days for this answer

> (In reply to comment #12)
> 
> > find a way to make it works, so it's not so hard to ask an application
> > password.
> 
> It is hard to ask for an application password without screwing up the whole UX
> for everybody -- including non-2-factor users.
> 

Maybe the simplest way of implementing 2-factor auth in Gnome is to do something similar to chrome/ium (I'm not sure  about actual implementation):

 - Give use log in dialog as previously
 - Allow user to log in using main password, get OAUTH token, save password
 - Optionally: Verify that token works
 - Check if password works. If it does not than say something "It looks like you use 2-factor authentication. You need to enter application-specific password as well" and provide input for password(In reply to comment #13)

I'd rather not have GNOME attempt man-in-the-middle password sniffing attacks at all. Please don't sacrifice trust in the name of convenience.

(In reply to comment #26)
> I'd rather not have GNOME attempt man-in-the-middle password sniffing attacks
> at all. Please don't sacrifice trust in the name of convenience.

I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack".  Dramatics sounds as bad coming from a developer as "XXX other big project can hack it, why don't you" from users.

(In reply to comment #25)
>  - Check if password works. If it does not than say something "It looks like
> you use 2-factor authentication. You need to enter application-specific
> password as well" and provide input for password

If you can give me a "hack this" pointer to a file in a git repo, I can have a go.  It might be enough just to make this bug report a bit more google-able.  Using an app-specific password certainly worked for me.

(In reply to comment #27)
> I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack". 
> Dramatics sounds as bad coming from a developer as "XXX other big project can
> hack it, why don't you" from users.

I don't believe it's a strawman argument. It's an unwritten contract of trust that my user agent does not save any passwords without me explicitly allowing it to. Especially so over secure connections and for fields with autocomplete="off". Especially so for use outside of the scope the password was originally entered in (the login form on the website).

How would it make you feel if a piece of software offered you a paid upgrade, displayed an embedded PayPal window and then decided it would be nifty to intercept and save your PayPal password without you knowing? For me that is a breach of the unwritten contract.

If you need a password, ask for it explicitly. Even if I have to retype it.

(In reply to comment #29)
> (In reply to comment #27)
> > I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack". 
> > Dramatics sounds as bad coming from a developer as "XXX other big project can
> > hack it, why don't you" from users.
> 
> I don't believe it's a strawman argument. It's an unwritten contract of trust
> that my user agent does not save any passwords without me explicitly allowing
> it to. Especially so over secure connections and for fields with
> autocomplete="off". Especially so for use outside of the scope the password was
> originally entered in (the login form on the website).
> 
> How would it make you feel if a piece of software offered you a paid upgrade,
> displayed an embedded PayPal window and then decided it would be nifty to
> intercept and save your PayPal password without you knowing? For me that is a
> breach of the unwritten contract.
> 
> If you need a password, ask for it explicitly. Even if I have to retype it.

While I see your point it is a dialog box explicitly for adding the account to system. I believe it is explicit by unwritten rules that it saves some information which allows the client to connect to server at any time (at least - the same assumption is made in Android, Windows 8, IOS etc.) - you can still log in each time just by adding account in application and requesting it not to save password. On the other hand the example you have given there is no such unwritten contract. It is not 'add PayPal account' but 'log into PayPal account' hence implying one-time use of the account. And presence in system settings instead of application settings implies that it affect system-wise instead of application-wise.

The only possible worrisome element is user might think that only OAUTH token is saved and not the password itself (not using OAUTH token from what I understand is lack of support on Google side not Gnome side).

(In reply to comment #30)
> The only possible worrisome element is user might think that only OAUTH token
> is saved and not the password itself (not using OAUTH token from what I
> understand is lack of support on Google side not Gnome side).

That's the whole point. OAUTH provides a simple, revokable way to grant an application limited access to your account. On the other hand giving an app access to your master password gives it unrevokable and unlimited access to everything you can do as the application is therefore able to act as the owner of the account.

To make things worse, gnome-online-accounts also breaks the per-application part of the OAUTH protocol as it effectively makes the whole desktop a single application. I would much rather have it act as an OAUTH mediator that apps can use to request a *private* OAUTH key so in the end the Flickr app is not able to delete your Google documents (even if its author swears that it would never do that).

(In reply to comment #31)
> (In reply to comment #30)
> > The only possible worrisome element is user might think that only OAUTH token
> > is saved and not the password itself (not using OAUTH token from what I
> > understand is lack of support on Google side not Gnome side).
> 
> That's the whole point. OAUTH provides a simple, revokable way to grant an
> application limited access to your account. On the other hand giving an app
> access to your master password gives it unrevokable and unlimited access to
> everything you can do as the application is therefore able to act as the owner
> of the account.

I thought the only reason GNOME stores the password is that not all Google protocols support OAuth yet?

Saving the password does not necessarily mean that it is a man in the middle attack. That would be an exaggeration. The password is stored in the encypted keyring as any other secret and not a plain text file. When you add an account using the Online Accounts panel it means you are giving access to GNOME (ie. all core components of GNOME), and not just a single application. If you are not comfortable with doing that, then don't add your account.

Even if only used OAuth2, even then you are granting GNOME the permission to access your account and data, and it can potentially impersonate you or tamper your data. So unless you trust GNOME, you should not be adding your account.

It is technically impossible to limit the access to a single application because we don't have any sandboxing facility. Any application is free to read the OAuth2 token or whatever secret you use, no matter what you do. Once we have a sandbox it will be possible to impose such restrictions on applications.

A password is used because of the way Evolution Data Server interacts with Google Calendar. Currently it fails to use a OAuth2 token, and since it throws a system modal dialog asking for the password, it is hard for people to supply an application-specific password, which is typically too long to be memorized.

The correct fix is to implement a backend for EDS that can work with Google Calendars using OAuth2 tokens. See bug 686804

Either subscribe to the EDS bug or provide a patch. Just piling on comments on this bug will not magically solve anything. :-)

*** Bug 694996 has been marked as a duplicate of this bug. ***

Adding an app specific password in seahorse made contacts and mail work but calendar is still broken for me.

Correcting myself, calendar is now also working. Waiting a day autofixed it...
I don't understand why but as it is working, I'm happy.

To give you a sense of purpose, google 2-factor and integration into gnome is the feature that convinced me into upgrading my gnome system, thank you for this great feature!

The original comments explaining what was happening said that only Calendar and GTalk are affected. But Contacts doesn't work for me either. Neither does Google Drive in Documents. Is that expected? I also tried it in Gnome 2.7.92 and none of these things work there either. 

I think at the very least we need to introduce a message to the user saying "2-factor isn't supported" when detected and a fallback to an application specific password should be supported and provided in any case.

Sorry, I meant Gnome 3.7.92 of course.

Wow, still not fixed? I'd actually like to use GOA but if I have to disable 2-step verification, this is a no-go

probably it's not so secure as it seems, and may be it's a good luck they does not fix it at all ;)

http://nelenkov.blogspot.ru/2012/11/sso-using-account-manager.html

Gnome Shell 3.8
Two factor authentication

login with Google username and password, enter verification code
password expires instantly.

Workaround:
open seahorse, find goa, replace password with generated one time password.

Seems fixed

same issue - same solution as comment 41. the only comment: instead of replacing the whole text in the password field of seahorse, edit the field, there are many attributes in there besides the password - and just replace the password field. After that, I logged out and back in and voila, it worked. Empathy and Documents working fine now.

It looks like Google CalDav now supports OAuth2

http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html

https://developers.google.com/google-apps/calendar/caldav/v2/guide

This is blocking on evolution-data-server (see bug 686804). EDS needs to implement authenticating to CalDAV using OAuth2. There is nothing left to do in GOA apart from deleting the raw password sniffing code.

Closing.

In case someone wants to test, you need gnome-online-accounts-3.9.4 and evolution-data-server-3.9.5 (ie. Git master at this moment).

*** Bug 706473 has been marked as a duplicate of this bug. ***

*** Bug 707965 has been marked as a duplicate of this bug. ***

*** Bug 707969 has been marked as a duplicate of this bug. ***