GNOME Bugzilla – Bug 774202
Change the API key for Google to shield against buggy versions of evolution-data-server
Last modified: 2016-12-16 13:17:16 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)
repro'd for me.
This error is popping up in gnome-todo as well.
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:
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.
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.
(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.
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.
(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?
(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
(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.
Yes, I misunderstood.