From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cesar Crusius Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Fri, 07 Aug 2020 17:01:46 -0700 Message-ID: References: <87v9ienz6c.fsf@gnus.org> <878sf9c69y.fsf@gnus.org> <871rkw62t3.fsf@gnus.org> <87mu36e206.fsf@sinax.be> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32846"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Michael Anckaert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 08 02:03:20 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 1k4CKV-0008Qg-9m for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Aug 2020 02:03:19 +0200 Original-Received: from localhost ([::1]:59780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4CKU-00027S-9m for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Aug 2020 20:03:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4CJH-0001Dv-VD for emacs-devel@gnu.org; Fri, 07 Aug 2020 20:02:03 -0400 Original-Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:34908) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k4CJD-0001Kk-4m for emacs-devel@gnu.org; Fri, 07 Aug 2020 20:02:03 -0400 Original-Received: by mail-pl1-x634.google.com with SMTP id r4so1970138pls.2 for ; Fri, 07 Aug 2020 17:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=mxz4Ze5Tqyp70+PuiCrJQUtZCHThmsGNA1zvPVu88RQ=; b=FF0yZLzqMzABDgFNxBtAxwDSl0wZTOP6/pu9o9tvfxqDfapwbYTpuM6QRAEaGyrYty laDj27Sm5r7XmtWqbIaBrmd1sYde7HNiiEkDvjytAo5SrDoV1qQ+ffKGq7IP+PAKit+n 6wi+cnaqIK56AshmOIlmqdpJFxNxZ6KOvBHcbGwUCN57eXf/fpvJClNK7U4sNz4mdveX onMLRfp+weCjWIqNfEytkEERHVuY/O4wVW7p6L9C5/tvZPeC5YhBe/FL60h1j38WmypP ZAvVLSEyujMOf9QIN1G9kNkwo3dA11lUs86LWsq8TZw29GUkdUUY0t0I8zEn9i7ap8Bo ePAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=mxz4Ze5Tqyp70+PuiCrJQUtZCHThmsGNA1zvPVu88RQ=; b=mTRfOfnz1zBzjtkO5KTfRy5W2DRdRxVtkIA4PGn7Q/KnpuGYBNlWqP3rgVq8uiyHqz uB38RLYMNNE6jFlGimAtAySCbeclUXM9SWPG81/HfNo+U8FsUsEkPh7lv5DunhhT0dg0 lMdhA/A8UobSCtZ0Bj1rZFqxGYKxZxNuq0L9I1/fG5U/hnzcrU7ZO41Aj7UBgnGAMZ0B nWhn4sK2X6hAbA1XlRrtlPP+5K4gwfYHJp1bUveYStIvN68kpqeqaPvIcd/7dso1AwWF y/qLlWLaIc8qzrFe2eMsy3o4WrNmmXQUXPdDrEhpp92j8TORGq8RijriiJops9maf7Q0 RMWA== X-Gm-Message-State: AOAM532v3FXLHz/jSNz7ZaSjCBGoDz2bKtbhtesmLRcFGC0CaxLwxS0x GHJZo+i0Q6xaju1wLvD5OhxRSAbS6/8= X-Google-Smtp-Source: ABdhPJz/FrtgJB0ZYs12FwJexS4Tfkqd52KgJkk6/rjzWXG9cWwboZ0xLO+RawbLTb5DPT6C+7ewsg== X-Received: by 2002:a17:90b:d87:: with SMTP id bg7mr16883084pjb.159.1596844916505; Fri, 07 Aug 2020 17:01:56 -0700 (PDT) Original-Received: from ccrusius-glaptop (c-24-4-33-27.hsd1.ca.comcast.net. [24.4.33.27]) by smtp.gmail.com with ESMTPSA id n2sm12054295pgv.37.2020.08.07.17.01.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 17:01:55 -0700 (PDT) In-Reply-To: <87mu36e206.fsf@sinax.be> (Michael Anckaert's message of "Fri, 07 Aug 2020 20:37:13 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::634; envelope-from=cesar.crusius@gmail.com; helo=mail-pl1-x634.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, FREEMAIL_FROM=0.001, 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:253506 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Anckaert writes: > 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. This is exactly what the auth-source-xoauth2 package asks the user to do, w= ith documentation on how to do it *for Google projects.* > 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 use= r'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. One worry I have about this is that it wold be very Google-specific, as the= re are other places where this is necessary (Reddit came up as an example) = that have a quite different project registration workflow. The impression I get from all the discussion is that, in the end, OAUTH2 is= just extremely OSS-unfriendly, and currently there may be no better soluti= on than simply say "go register a project and generate the keys" in various= levels of detail. My personal take on this is that documentation serves the purpose better, b= ut I'm not against utility functions that guide you through the setup. I kn= ow, for example, that the Google Cloud Developer console is *extremely* acc= essibility-unfriendly, to the point of being unusable (T.V. Raman can corre= ct me here if I'm exaggerating) - the workflow you sketched above would not= solve that problem, as the user still has to navigate the Google interface= to do things. =2D-=20 Cesar Crusius --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEsu/ErKn7yEV7E0FU/X9qSDfQj2EFAl8t62oACgkQ/X9qSDfQ j2Fr0Qv/Zu8+uYW4IOmpZ7bIBpiFk2peVjbe+MovEckOkc0Nu4GCym49Mip3fUmv D9yxox1GC4Rkt5/fF5aO2dvHJxU5SBfClStXlip9esG5cMch//DK0BIgb6Lbx8sw kjE4xlEgPBQLWXvWqZwF/6EHWuYVlmpoPmhiq+Y1WflFI1BbzmfvOwwfeZ804o1i Dh1xbY0CTFmHXevxW0KWNGduDS4/HZs/tOiX9fE1S/s2NNdxZbv67ky0uYMHxYYk L4o7pwMpCsZ0eoUkhF8OZeHeQyCGT+24t7xY3PXmFx/iFwehGVRn67+c3dVpdQl+ F2Z1x/eoVtfcbbOmuoephCtlMaWdy9JOIZas6ybbsCelT9EB5v2saEg7I3urW/QX 7exmJo3wYLc9AbLk9UGqUHK6lXat2ScRWxQnPPHWLgl5xJ8601qsKDQHtw0ElRzh bsFHOdgn0jneoIEyHZaPczVw1LsYcH0d9hE3ZioPyHQ0YJu6zHyFrJE4y4rnAmeL ZKUrzLYN =pjhO -----END PGP SIGNATURE----- --=-=-=--