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: Mon, 17 Aug 2020 17:05:58 +0100 Message-ID: References: <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> <87364pbkn0.fsf@gnus.org> <87lfihe0zf.fsf@mat.ucm.es> <874kp55l8t.fsf@gnus.org> 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="11908"; 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-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 17 18:13:53 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 1k7hlg-0002xs-R6 for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 18:13:52 +0200 Original-Received: from localhost ([::1]:40700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7hlf-0008OS-Qc for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 12:13:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7heC-0001Hb-N2 for emacs-devel@gnu.org; Mon, 17 Aug 2020 12:06:08 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:46144) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7he7-0003BA-Mb for emacs-devel@gnu.org; Mon, 17 Aug 2020 12:06:08 -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 451813C07F for ; Mon, 17 Aug 2020 16:06:00 +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/17 12:06:00 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 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:253892 Archived-At: On 17/08/2020 08:51, Gregory Heytings via Emacs development discussions. wrote: > (Note that doing this (that is, including an app key in free software) > also violates Google's terms of service.  But apparently Google > tolerates that these terms are violated by Kmail, Thunderbird and > others, so would presumably also tolerate that they be violated by GNUS.) > Well, they're legal terms not program code. Apart from them just tolerating/overlooking it, things can also happen between parties under terms different to or supplemental to some generic published standard terms, Cesar's point that the FSF could talk to Google about it on an official basis certainly stands. The legal side may just not have caught up with evolving native app / public client not-a-secret usage anyway, the terms seem more suited to traditional server-side web apps, still a common use case for oauth2 (contrast e.g. [1] and [2]). I expect it's actually Mozilla and KDE representatives that self-service manage their respective registrations via the relevant google api console, not Google employees, in their cases, but it is also possible to imagine (however unlikely in practice) Google and the FSF taking a different approach and agreeing to a Google employee instead managing and issuing on their side some client id(s) for various uses to the FSF i.e. rather than an FSF representative agreeing to the generic terms and logging in and self-service managing clients (though that has associated loss of self-service control e.g. branding during the auth flow etc). Then sending the client to the FSF under some sort of alternative legal terms along the lines of "actually this here client id can be embedded in emacs gnus sources under the GPL, it's fine, despite what those generic terms say, Note it will only actually work for oauth2 if auth code with pkce and a localhost redirect_uri flow is used. And google may also temporarily or permanently cease recognising this client id at any time for any reason, and a new client id may or may not be issued". A Google employee contributing an actual source code patch with such a client id embedded would make that rather on-the-record. Not saying that is especially desirable or google would be likely to go for that option anwyay, just seems another possible in principle thing worth mentioning. [1] https://auth0.com/docs/flows/authorization-code-flow """ Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow (defined in OAuth 2.0 RFC 6749, section 4.1), which exchanges an Authorization Code for a token. Your app must be server-side because during this exchange, you must also pass along your application's Client Secret, which must always be kept secure, and you will have to store it in your client. """ [2] https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce """ When public clients (e.g., native and single-page applications) request Access Tokens, some additional security concerns are posed that are not mitigated by the Authorization Code Flow alone. This is because: Native apps Cannot securely store a Client Secret. Decompiling the app will reveal the Client Secret, which is bound to the app and is the same for all users and devices. [...] To mitigate this, OAuth 2.0 provides a version of the Authorization Code Flow which makes use of a Proof Key for Code Exchange (PKCE) (defined in OAuth 2.0 RFC 7636). """