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: Sun, 16 Aug 2020 18:23:18 +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> <87bljb1ywk.fsf@cesars-w520.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19420"; 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 Sun Aug 16 19:24:14 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 1k7MOE-0004wg-4J for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 19:24:14 +0200 Original-Received: from localhost ([::1]:53178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7MOD-0002lD-6O for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 13:24:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7MNQ-0002Lp-0K for emacs-devel@gnu.org; Sun, 16 Aug 2020 13:23:24 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:43010) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7MNO-0007uC-9u for emacs-devel@gnu.org; Sun, 16 Aug 2020 13:23:23 -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 840313C069 for ; Sun, 16 Aug 2020 17:23:20 +0000 (UTC) In-Reply-To: <87bljb1ywk.fsf@cesars-w520.i-did-not-set--mail-host-address--so-tickle-me> 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/16 13:23:20 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 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:253857 Archived-At: On 15/08/2020 20:39, Cesar Crusius wrote: > From what I've seen from Kmail/Kontact/KPim/etc replies, (a) and (b) is exactly what they are doing, and there's no way around this. The only question is how to achieve those in a way that is compatible with both Google terms and FSF requirements, if there is such a way. Thunderbird "achieves" (b) by having "secret" keys in source code. I don't know what the K* applications do, it did not seem to be specified in their discussions. > For the morbidly curious like myself: N.B. I'm far from familiar with the sprawling KDE sources in general, but it's freely licensed (LGPL), so had a quick look. Anyway, their source-embedded static values were trivial to locate at time of writing: https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/imap/gmailpasswordrequester.cpp#L16 https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/google-groupware/googlesettings.cpp#L143 https://invent.kde.org/pim/kmailtransport/-/blob/master/src/kmailtransport/plugins/smtp/smtpjob.cpp#L32 The referenced kde KGAPI component (implements enough oauth2 to work against google) appears to be use the spawn-transient-http-server-on-localhost redirect_uri approach/trick to pick up the authorization code (to convert to access+refresh tokens with second request). Don't seem to be doing code_challenge/code_verifier i.e. pkce /rfc7636 yet (presumably should). To make the request they actually currently appear to use / still use embedded webview, not delegating to user's browser, in contrast to recent https://tools.ietf.org/html/rfc8252#section-8.12 (skipping pkce and embedded webview may be "grandfathered in", can well imagine google and other providers frowning on it for newly-issued app client ids) https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget.cpp#L100 code req to auth endpoint https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget.cpp#L121 code response receipt https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget_p.cpp#L277 code->token req to token endpoint https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/private/newtokensfetchjob.cpp#L88 token response processed https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/private/newtokensfetchjob.cpp#L124