From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Thu, 13 Aug 2020 16:39:44 +0100 Message-ID: References: <87v9ienz6c.fsf@gnus.org> <878sf9c69y.fsf@gnus.org> <871rkw62t3.fsf@gnus.org> <87bljki71n.fsf@mat.ucm.es> <87364wxlec.fsf@gnus.org> <87imdsgmlw.fsf@mat.ucm.es> <871rkfhkhc.fsf@mat.ucm.es> <875z9p5hnc.fsf@mat.ucm.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17123"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 13 17:40:29 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k6FLB-0004JA-Ev for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Aug 2020 17:40:29 +0200 Original-Received: from localhost ([::1]:56546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6FLA-0006jj-AM for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Aug 2020 11:40:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6FKb-0006JD-39 for emacs-devel@gnu.org; Thu, 13 Aug 2020 11:39:53 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:58308) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6FKY-00031d-6P for emacs-devel@gnu.org; Thu, 13 Aug 2020 11:39:52 -0400 Original-Received: from [192.168.1.103] (87-198-55-78.ptr.magnet.ie [87.198.55.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA 4" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id AB98D3C07F for ; Thu, 13 Aug 2020 15:39:46 +0000 (UTC) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=65.99.215.13; envelope-from=david@harpegolden.net; helo=harpegolden.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/13 11:39:47 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253738 Archived-At: 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?