After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774202 - Change the API key for Google to shield against buggy versions of evolution-data-server
Change the API key for Google to shield against buggy versions of evolution-d...
Status: RESOLVED FIXED
Product: gnome-online-accounts
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME Online Accounts maintainer(s)
GNOME Online Accounts maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-11-10 12:41 UTC by Dominique Leuenberger
Modified: 2016-12-16 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dominique Leuenberger 2016-11-10 12:41:19 UTC
Seems GNOME's success is starting to be a curse: every day (the later, the more likely, it varies a lot) evolution starts complaining that it can't load Calendar and Contacts from Google anymore.

The info bar contains:

 Daily Limit Exceeded - The quota will be reset at midnight Pacific Time'

There is a URL presented in the info bar bringing you to google developer's API configuration, but the regular user can't do anything (no permission) 

This is quite annoying and a real problem to reliably work with GNOME and the Google integration.

(A user on IRC reported he'd seen the same when accessing google drive from Files at that time - which makes me believe that g-o-a is a center piece there)
Comment 1 marfree 2016-11-27 06:37:10 UTC
repro'd for me.
Comment 2 Eric Donkersloot 2016-12-08 22:35:16 UTC
This error is popping up in gnome-todo as well.
Comment 3 Eric Donkersloot 2016-12-08 22:41:01 UTC
Same issue with gnome-calendar:

** (gnome-calendar:2765): WARNING **: source_credentials_required_cb: Failed to authenticate 'Contacts': Failed to login to the server: Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API Console:
Comment 4 Debarshi Ray 2016-12-14 08:41:16 UTC
There were a few bugs (bug 771547 and bug 773248) in evolution-data-server that were causing us to hit Google's daily limit for the CalDAV and Tasks APIs. It was essentially polling the server very very aggressively.

The bugs have since been fixed, but until every single user out there installs the fix, everybody using the old keys will be susceptible even if they have a fixed copy of evolution-data-server. This is because Google identifies us by the API key and not the version of the code running on the client.

We are changing the upstream API key for Google (commit 43a20cfe4d) to address this. It is already in 3.23.3. I will shortly be releasing 3.22.x and 3.20.x versions with the new key.

In short, you need a fixed evolution-data-server to stop your clients from misbehaving, and you need a new gnome-online-accounts to shield yourself from other misbehaving clients.
Comment 5 Jeremy Bicha 2016-12-14 19:25:51 UTC
Is there any way you can check whether a fixed version (3.20.6 or 3.22.2 I believe) of evolution-data-server is in use?

Otherwise, you might end up tainting the new key too.
Comment 6 Debarshi Ray 2016-12-15 12:37:55 UTC
(In reply to Jeremy Bicha from comment #5)
> Is there any way you can check whether a fixed version (3.20.6 or 3.22.2 I
> believe) of evolution-data-server is in use?
> 
> Otherwise, you might end up tainting the new key too.

Ideally, people should have both the new e-d-s and the new g-o-a, but I am not sure how we can enforce that. Maybe the e-d-s package could require a new g-o-a, but that still leaves the possibility that someone might use a newer g-o-a with a broken e-d-s and taint the key.

Or we can just cycle the key again in 3.24, which should have pristine versions of everything.

I don't know of a good solution here.
Comment 7 Jeremy Bicha 2016-12-15 19:14:31 UTC
OK, maybe you could send an email to the distributor-list@gnome.org to give a brief explanation of the situation to distro packagers.

Also, since the issue was with older versions of e-d-s 3.20 and 3.22, I assume it's ok if I backport this new key to Ubuntu 16.04 (and earlier supported distro releases) which shipped with e-d-s 3.18. Even the GNOME3 Staging PPA for 16.04 which now includes e-d-s 3.20.6 but has always built with --disable-google-auth since we didn't want to add a webkit1 dependency.
Comment 8 Debarshi Ray 2016-12-15 23:01:07 UTC
(In reply to Jeremy Bicha from comment #7)
> OK, maybe you could send an email to the distributor-list@gnome.org to give
> a brief explanation of the situation to distro packagers.

Yes, that's the plan. I now have a blog post that I can point people to:
https://debarshiray.wordpress.com/2016/12/15/new-gnome-api-key-for-google-services/

> Also, since the issue was with older versions of e-d-s 3.20 and 3.22, I
> assume it's ok if I backport this new key to Ubuntu 16.04 (and earlier
> supported distro releases) which shipped with e-d-s 3.18.

e-d-s-3.18 didn't get fixed upstream. So, if you want to ship the newer Google API key with it, then you will have to somehow backport the e-d-s fixes too. Or maybe convince mcrha to make upstream releases for e-d-s 3.18 too? If that happens then I will be happy to make a new g-o-a release for 3.18.x.

> Even the GNOME3
> Staging PPA for 16.04 which now includes e-d-s 3.20.6 but has always built
> with --disable-google-auth since we didn't want to add a webkit1 dependency.

You mean evolution's own standalone OAuth2 thing? In any case, you should be all set for 3.20.x because you can just carry the latest upstream g-o-a tarball. Or am I missing your point?
Comment 9 Jeremy Bicha 2016-12-15 23:56:09 UTC
(In reply to Debarshi Ray from comment #8)
> e-d-s-3.18 didn't get fixed upstream. So, if you want to ship the newer
> Google API key with it, then you will have to somehow backport the e-d-s
> fixes too. Or maybe convince mcrha to make upstream releases for e-d-s 3.18
> too? If that happens then I will be happy to make a new g-o-a release for
> 3.18.x.

If I understood correctly, mcrha says that only 3.20 and 3.22 were affected by the bugs so there is no need to backport e-d-s fixes to 3.18 or earlier releases. https://bugzilla.gnome.org/show_bug.cgi?id=771547#c62
Comment 10 Debarshi Ray 2016-12-16 13:11:36 UTC
(In reply to Jeremy Bicha from comment #9)
> (In reply to Debarshi Ray from comment #8)
> > e-d-s-3.18 didn't get fixed upstream. So, if you want to ship the newer
> > Google API key with it, then you will have to somehow backport the e-d-s
> > fixes too. Or maybe convince mcrha to make upstream releases for e-d-s 3.18
> > too? If that happens then I will be happy to make a new g-o-a release for
> > 3.18.x.
> 
> If I understood correctly, mcrha says that only 3.20 and 3.22 were affected
> by the bugs so there is no need to backport e-d-s fixes to 3.18 or earlier
> releases. https://bugzilla.gnome.org/show_bug.cgi?id=771547#c62

Since 3.20, evolution has its own OAuth2 stack so that you can use it standalone without gnome-online-accounts if you want. That is what he meant by "internal Google OAuth2 authentication".

As for the actual bug that led to the quota being exhausted, it does affect versions older than 3.20 also. So if, and only if, there are upstream evolution-data-server releases for older branches, I will be happy to make matching gnome-online-accounts releases. Otherwise it will be upto the downstream distributors themselves.
Comment 11 Jeremy Bicha 2016-12-16 13:17:16 UTC
Yes, I misunderstood.