From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Anckaert Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Fri, 07 Aug 2020 20:37:13 +0200 Message-ID: <87mu36e206.fsf@sinax.be> References: <87v9ienz6c.fsf@gnus.org> <878sf9c69y.fsf@gnus.org> <871rkw62t3.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33145"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.12; emacs 26.3 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 07 20:38:11 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 1k47Fq-0008WG-II for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Aug 2020 20:38:10 +0200 Original-Received: from localhost ([::1]:59496 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k47Fp-0005fD-K7 for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Aug 2020 14:38:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k47F4-00052l-8G for emacs-devel@gnu.org; Fri, 07 Aug 2020 14:37:23 -0400 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:34850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k47F1-000852-HW for emacs-devel@gnu.org; Fri, 07 Aug 2020 14:37:21 -0400 Original-Received: by mail-ed1-x533.google.com with SMTP id m20so1955139eds.2 for ; Fri, 07 Aug 2020 11:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sinax.be; s=google; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=zECW4YGCB7kAsSGXsur4Z9VdhqqcbG+Kf8vzZOOSsAE=; b=OaV/JJsSPYFHyqIt1X+5VU1N6jqHVlJS/qgN/qAex3UvbY2I6oNJ+KUrjOMLRh4btu A7x7bJKS2frYkdT2HnfLyuAIY0uB6H3Sxk9MF3Rl+DffCrZNS0+2Cf0AigYkcTnE+jeY U1guajah3nFXnD3FFPMbzbNpHY/jFlae5uE3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version; bh=zECW4YGCB7kAsSGXsur4Z9VdhqqcbG+Kf8vzZOOSsAE=; b=qS/d02Wh/5FRz+QuqxtnpFYGwLUyYvxdMqQ1eBM1ITJooeIbLdxEVpRS2p9lhM49fg 0cghqCMmjjXtx7G5WdJUKKk/ZrSQqX1tqXkfJ7HglEt5fxQKx2mUgFUnzArZ98KgpunH 8jOR9pNK/k3B9xw9Ir/6Ds/4PWBYfYMAJtJVlh/17Fx600ZXBW4L5+8JEE3U4+f27fHF V8FJ5BAAugPfNeKUgcgJrVnerAhIQHGhOrgd2h8UhKWBHqXxt+bC+FEv85+4O69B58JZ yrjnsU+NJ1ZGrXuEhxFzjTb8liHTBIne4JDo7x9ME3mq7lQGnfpxpkBJK2Chqug+vWY6 Is7Q== X-Gm-Message-State: AOAM531f1yhl04f1DVhTz2UtuWEMo32h8E8WwrvTHn9RHomGWaBCge8s OpEDiYDHcgUIp9YmRloq0/51BvIHFDExTA== X-Google-Smtp-Source: ABdhPJyopmmIXc+sN4mo6B42K4qIT5oDWtkJnZOUaUlwfX+9S/w84npNQ4/1LFIgTs6qIoK6ft2Wsw== X-Received: by 2002:aa7:ce90:: with SMTP id y16mr10274961edv.325.1596825436410; Fri, 07 Aug 2020 11:37:16 -0700 (PDT) Original-Received: from winston (ptr-dkbjq8c317ly3d4pfb3.18120a2.ip6.access.telenet.be. [2a02:1811:c412:9000:f7d8:8cd0:7235:a1bf]) by smtp.gmail.com with ESMTPSA id j11sm6397009ejx.0.2020.08.07.11.37.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 11:37:15 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=michael.anckaert@sinax.be; helo=mail-ed1-x533.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:253505 Archived-At: Cesar Crusius writes: > Richard Stallman writes: > >> [[[ To any NSA and FBI agents reading my email: please consider ]]] >> [[[ whether defending the US Constitution against all enemies, ]]] >> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >> >> > The person you want to reach out to is probably >> > dvratil@kde.org. Here's a relevant blog post from him, about how >> > he fixed the Kontact Oauth2 problem: >> >> > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/ >> >> Lars, is this something you can do? >> >> > My auth-source-xoauth2 package "avoids" that by having every user >> > do the API key dance with Google, and as a result is rather hard >> > to setup. >> >> Aside from the inconvenience, is there anything about this we simply >> cannot ask users to do? Does it require accepting terms that are >> unjust and not required for using Gmail itself? > > I went through the process a long time ago, so I can't answer that with certainty. The current legalese is in the pages here: > > https://developers.google.com/terms > > Somebody with a keener legal eye could look at it, but there are certainly more/different terms there. > > As an aside, it is worth noting that my package is not Gmail-specific. It could be used for the Reddit example given before via similar means: register a project/app in Reddit, get the keys, etc. > > The crux here is that there needs to be an app - their intent is that the software producer (in this case an "Emacs" or "Gnus") registers an "official" app, and the app manages its secrets in a way compliant with their terms (which we already know is pretty hard for OSS projects). I've picked up this discussion from the list archives and decided to chime in with some information I have. Since I lack the previous emails in this discussion, please excuse me replying out of sync. Including the client ID / secret key in Emacs source code (as Thunderbird does) is bad practice. In addition, I believe there might be some legal / moral issues with registering an FSF application under the Google TOS. The only suitable alternative would be to have the user register his own Google Cloud Project and use that client ID to run the OAUTH2 flow. This approach differs in that instead of having one client and many users, we have one client for every user. In the past I've written a number of software packages for companies that had to make use of Google API's using OAUTH2 authentication. In some cases we couldn't include the client secret in those packages (various departments had their own Google Cloud projects and API usage guidelines). So in essence I had the same issue as what Emacs is facing now. The solution was to have the software prompt the user to create a specific project on Google Cloud and specify the client secret in the application configuration. A similar approach could be chosen for Emacs so that instead of having a single client ID for Emacs, every user creates his/her own project and configures the client ID in his/her Emacs configuration. Then the OAUTH2 flow has to be run for that 'Emacs application'. The flow as I once implemented it could be adapted to Emacs as follows: * The Emacs documentation specifies the user what type of Google Cloud project has to be created and what client ID / secrets have to be configured. * After configuring this information, the user starts an Emacs command (eg M-x retrieve-oauth-credentials) * This command starts a local webserver and opens the address in the user's browser * The webpage displayed allows the user to start the OAUTH2 flow which redirects to the local webpage with the OAUTH2 token * Emacs stores the OAUTH2 token in a suitable location I would have to check back to some code I have stored to verify the entire flow and make sure I didn't miss anything. But in essence the flow above is what would be required. If deemed suitable, I'm willing to aid in development of this feature if someone can spend some time mentoring / guiding me on the required steps and correct implementation details. -- Michael Anckaert michael.anckaert@sinax.be +32 474 066 467 https://sinax.be