[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making GNUS continue to work with Gmail
From: |
David De La Harpe Golden |
Subject: |
Re: Making GNUS continue to work with Gmail |
Date: |
Thu, 13 Aug 2020 16:39:44 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 11/08/2020 17:11, Robert Pluim wrote:
The alternative is to register an 'Emacs' app, do the hoop jumping,
and stick the various secret tokens in the Emacs sources, but as I
understand it thatʼs expressly forbidden by Google's terms-of-use
(correct me if Iʼm wrong, I haven't read them).
Just looked vaguely into this as a thunderbird and emacs user /
emacs-devel ghost. I was left seriously wondering how+why thunderbird
was still working with a gmail account (just a secondary email in my
case, fortunately), having seen this thread. Anyway, decided to write it
up and share it in case it's useful. Sorry for wall of text, tried to
structure it somewhat:
*1. Non-secret "client secrets".
*2. What Thunderbird does data point, and not just a google problem
*3. End-User supply of and/or override of client id and secret
*4. Technical implementation note, separation of implementation vs
official id concerns
*1. Non-secret "client secrets":
That assumption that people including google really think these
particular "secrets" are real secrets that are required to be be kept
secret may be false? Google do appear to recognise and accept such
desktop app hardcoded static client ids and "secrets" they issue aren't
actually secret in this case, just some bits anyone can easily snaffle e.g.
https://developers.google.com/identity/protocols/oauth2/native-app
"""
Note: incremental authorization with installed apps is not supported due
to the fact that the client cannot keep the client_secret confidential.
"""
Regarding "not supported" there - in context that doesn't mean authc and
non-incremental authz don't work, my point quoting the above was not
that aspect of it, just that you can see they appear to be well aware
the so-called client secret is not a secret in any meaningful sense in
the overall native-app-installed-on-client-desktops flow they are
talking about.
And let's see the rfc8252 google cite, note it says (quite amusingly):
https://tools.ietf.org/html/rfc8252#section-8.5
""""
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret.
"""
And IIUC a near-mandatory protocol extension (pkce rfc7636,
https://oauth.net/2/pkce/ ) means core security properties are not or no
longer strongly linked to these particular "secrets" being secret.
=> I think they're not real secrets? Not to say a lot of attention to
the legal side wouldn't still be required if an official client id and
secret were sought.
Google further apparently doesn't support "dynamic client registration"
(I think unlike a lot of in-house corporate auth servers using oauth2 on
intranets as a "modern" kerberos replacement?), so such valid static app
client ids and secrets can only be obtained via their full web interface
for issuing and approval workflow, which would certainly still involve
agreeing to lots of incomprehensible legalese things.
https://stackoverflow.com/questions/36260097/is-openid-connect-dynamic-client-registration-possible-with-google
*2. What Thunderbird does data point, and not just a google problem:
Now, definitely no idea of legalities it happens under either, nor
advocating emacs should necessarily take the same approach, but as a
data point, it looks to me like Mozilla Thunderbird (MPL2.0 licensed) at
time of writing does appear to be simply openly embedding a bunch of
static oauth2 app client ids and client (non-)secrets for
Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft
https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51
*** If nothing else, seems clear it is already becoming not just a
google problem.
Presumably someone from Mozilla applied for and got those ids and
secrets from each provider.
And of course, even if it's legally okay for someone acting for GNU to
similarly get some static client ids and (non-)secrets issued from
google (and the others) to similarly embed openly in the GNU Emacs
official sources, subject to their approval whims whatever they may be -
and seems like a "pray I do not alter the deal further" scenario, sigh,
can certainly imagine them just turning it off later. Or turning on
billing: given google, I'd also be vaguely suspicious about them not
using it super-maliciously, but being able to use it as a key (in a db
sense) for trying to charge an app developer instead of an end user,
*3. End-User supply of and/or override of client id and secret:
There is strong precedent there in that the chromium codebase itself
also supports env vars setting of arbitrary user-specified runtime
override api access client ids and secrets when it doesn't have its own
hardcoded embedded ones compiled in, or if a dev just wants to use
different ones:
https://www.chromium.org/developers/how-tos/api-keys
I believe e.g. debian doesn't or didn't build their chromium with them,
but still allows users to supply their own if they want by that mechanism.
*4. Technical implementation note, separation of implementation vs
official id concerns:
Also to note Julien Danjou appears to have already written an emacs
oauth2 package:
https://elpa.gnu.org/packages/oauth2.html
(defun oauth2-auth-and-store (auth-url token-url scope client-id
client-secret &optional redirect-uri state)
(and with the likes of elnode, I guess the open a transient localhost
port redirect uri flow is viable to streamline token acquisition)
Presumably any emacs implementation for imap access use could easily
allow for end-user customizable override of either a prepopulated table,
or an empty table of the required provider, static client id, client
secret, mappings.
=> the technical side looks doable (especially since a lot of it looks
already done by Julien) and is not actually google specific (and may be
useful for both other public providers and private in-house ones in
companies etc.), it does look to me like the decision of whether to
implement the facility at all (that may still be playing into their
hands in a sense of course) could be made independently of whether to
actually apply for and embed an official static client ids and secrets
for the various public providers who apparently want one, including, but
not limited to, google in particular?
- Re: Making GNUS continue to work with Gmail, (continued)
- Re: Making GNUS continue to work with Gmail, Uwe Brauer, 2020/08/12
- Re: Making GNUS continue to work with Gmail, tomas, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Uwe Brauer, 2020/08/12
- Re: Making GNUS continue to work with Gmail, 황병희, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Stefan Monnier, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Uwe Brauer, 2020/08/13
- Re: Making GNUS continue to work with Gmail, Eric S Fraga, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Arthur Miller, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Eric S Fraga, 2020/08/12
- Re: Making GNUS continue to work with Gmail, Eric Abrahamsen, 2020/08/12
- Re: Making GNUS continue to work with Gmail,
David De La Harpe Golden <=
- Re: Making GNUS continue to work with Gmail, David Engster, 2020/08/13
- Re: Making GNUS continue to work with Gmail, Stefan Monnier, 2020/08/13
- Re: Making GNUS continue to work with Gmail, Lars Ingebrigtsen, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Richard Stallman, 2020/08/15
- Re: Making GNUS continue to work with Gmail, Lars Ingebrigtsen, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Uwe Brauer, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Lars Ingebrigtsen, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Uwe Brauer, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Cesar Crusius, 2020/08/14
- Re: Making GNUS continue to work with Gmail, Richard Stallman, 2020/08/15