From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72358: 29.4; oauth2.el improvements Date: Fri, 02 Aug 2024 17:43:59 +0300 Message-ID: <37727.6936591201$1722609973@news.gmane.org> References: <87mslz8yzk.fsf@debian-hx90.lan> <9717.00003590144$1722349291@news.gmane.org> <87r0bbvt9d.fsf@gmail.com> <871q3a8y1j.fsf@debian-hx90.lan> <87y15f4a7g.fsf@debian-hx90.lan> Reply-To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38197"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Robert Pluim , Thomas Fitzsimmons , 72358@debbugs.gnu.org To: Xiyue Deng Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 02 16:46:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sZtXh-0009k5-2S for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Aug 2024 16:46:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sZtXR-0006qo-62; Fri, 02 Aug 2024 10:45:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sZtXM-0006qV-Co for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2024 10:45:45 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sZtXM-0001XO-4A for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2024 10:45:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=MG8KDfEmP5GCnBGcYZv66UtPeVW6vCxqPozTsWCj3OQ=; b=ixr2v+kx9ZGCL2sTVThYm0u4xJNkwUT9g69XIZGO0QVkWvgR8ElWHxvX0SrvK7tzIlQUg1riAY6xf/FLTMlVS0h1CwWy1l9Zv2VuC5yDE70lGF8jnh6Dn22qvFeda2yLcvAx3jp6rj1bCcV+/vg3PAmH9PF+ZcUy8krfNDpbmWywN6TCHnm7QMODcl5Syi105GSNe36GheaiLBpwRC8FqAAg9o4VF7ROrt0C5PE3hcKt4B4CCzC3Uj0XDUNtJbqlRQ/oZ0fYc/UsRExZdhOJX+7Ni1ryeq2wN0k5TrpTUX79x73UxK0xmXoOs/7Zqjv7YXoyTBVk33opne1t3vymoA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sZtXe-0002eq-8Z for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2024 10:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Aug 2024 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72358 X-GNU-PR-Package: emacs Original-Received: via spool by 72358-submit@debbugs.gnu.org id=B72358.172260990410138 (code B ref 72358); Fri, 02 Aug 2024 14:46:02 +0000 Original-Received: (at 72358) by debbugs.gnu.org; 2 Aug 2024 14:45:04 +0000 Original-Received: from localhost ([127.0.0.1]:53639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sZtWh-0002dS-FB for submit@debbugs.gnu.org; Fri, 02 Aug 2024 10:45:03 -0400 Original-Received: from thaodan.de ([185.216.177.71]:38004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sZtWe-0002cl-Cb for 72358@debbugs.gnu.org; Fri, 02 Aug 2024 10:45:01 -0400 Original-Received: from odin (dsl-trebng12-50dc75-154.dhcp.inet.fi [80.220.117.154]) by thaodan.de (Postfix) with ESMTPSA id 913BCD00044; Fri, 2 Aug 2024 17:44:01 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1722609841; bh=h08D4bWQEobjR6YAPGiQDTdaIz1C4dSm0T8zOpDuw8Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=IeWXppqJVWTe+BsYSZYP2FpYeg59zLtQAqpHf88G2b/d2jd7p6p58Yj6Y0am8B2HP f/j54+uQ6upbjDLHrXNpOCDmz9XhglIcrhum9+J0kzQQrKNlLg5HeBDZ+wQBPXJB8Y 6X1TRTGEW5Gdwlo11nLiHs6zav+/qdSYFN3pRWRqevQRSc/FMZBAryCVc4OlnPFjMh F38gmIXaAsuQc91DgRkwgGuhHAKj2hoQusYzSqgb4W0DE86FYknumCNr+kXoj/8z/G 6jcyWeM1F7ccM4DLoS0wAFCkV71wFl3jQxxgEpX0n7cWORQkG4w1OIHsxetlUJox/s b1gLmUe5aenXpYCsduSpuacab5rQk2ZZUlBsEARtpNJDhYILzVjis8Fn+fwOzx6azb 5CHkxMkHJL1Zqa593crPS/Ij0CTHjfa11OJwq2pjJWutsJUh0NRTGBu5RNEPWsj9j2 zuaU/Xi0eLFT1/1YNatn/dmR+OG+vRXQUOVQoWoKXsHXnJGsVUP6p2wWUIL7lGm344 n2FTawbmaZglP01+Km7rUKJsuS1ZxL602pBAbOTs2oC7eV+NVmLBftOfSswgDFmfzU 81BXmfxUrTUNaKUwtJE5qAHEz4g80EdgiNkrTRcq/vZeJ/aMr0/lHqKQgXXxhBmCVh +NCZlNwRQtymROXgCdQ45T58= In-Reply-To: <87y15f4a7g.fsf@debian-hx90.lan> (Xiyue Deng's message of "Fri, 02 Aug 2024 01:09:55 -0700") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:289640 Archived-At: Xiyue Deng writes: > Hi Thomas, > > Thomas Fitzsimmons writes: > >> Xiyue Deng writes: >> >>> Robert Pluim writes: >>> >>>>>>>>> On Tue, 30 Jul 2024 17:08:21 +0300, Bj=C3=B6rn Bidar via "Bug rep= orts for GNU Emacs, the Swiss army knife of text editors" said: >>>> >>>> Bj=C3=B6rn> Xiyue Deng writes: >>>> >> The fourth patch may need a bit of background: oauth2.el (optio= nally) >>>> >> uses plstore to save authentication data for future reuse, and = the >>>> >> plstore id for an account is computed using a combination of `a= uth-url', >>>> >> `token-url', and `scope'. However, this combination of data do= esn't >>>> >> guarantee uniqueness for accounts for a same provider, e.g. for= Gmail, >>>> >> the three parameters are the same for different accounts, and h= ence >>>> >> storing a second account information will override the first on= e. >>>> >>>> Bj=C3=B6rn> Would it make sense to plug OAuth2.el into auth-source= to store the >>>> Bj=C3=B6rn> authentication token safely inside an existing credent= ial storage? >>>> >>>> Bj=C3=B6rn> Various applications already do so when using the nati= ve credential >>>> Bj=C3=B6rn> storages such as Freedesktop.org or the macOS keyring. >>>> >>>> Yes. In fact there=CA=BCs the auth-source-xoauth2 package that does >>>> that. And oauth2 can already store stuff using plstore, so I=CA=BCm su= re it >>>> can be extended to use auth-source. >>>> >>> >>> auth-source-xoauth2 doesn't actually use auth-source >>> (e.g. ~/.authinfo.gpg) to store the data it needs, but use a custom file >>> storing an ELisp hash table to store the client-id, client-secret, etc. >>> It does advice the authentication code to use the calculated token. >> >> I have not seen it mentioned in this thread yet, so here goes: my >> url-http-oauth package in GNU ELPA supports storing credentials in >> ~/.authinfo.gpg and refreshing them. It would be nice if your OAuth2 >> work could get feature parity with it, then I could delete my package; >> feel free to copy any code that makes sense. (I do not use >> url-http-oauth anymore, but I felt the need to write it when I was using >> Excorporate and OAuth.) >> > > Thanks for working on url-http-oauth! I think it adds credential > management using auth-source, e.g. prompt for client-id and > client-secret and store them, which my other addon (that I'll post next > as it depends on the changes I made here) didn't do. Ideally this > should be handled transparently by all auth-source backends and say Gnus > when you add a new account, but IIUC currently the JSON backend doesn't > support creation, which I'm using for ease to read and modify. I think depending on the authentication storage it would make sense to provide a custom setting with a sane default that allows the user to configure a path inside the storage to store their credentials. These could then have templates for the hostname, user, port etc just like the regular search parameters that `auth-sources-search' supports. >> Ideally you could get the result (and the xoauth2 support for IMAP and >> SMTP) accepted in Emacs core. >> > > That would be great! My other addon uses advice, but it would > definitely be better to be integrated in core (which already has partial > support) > >From Gnus point of view I think it would make it easier to support auth-source as then Oauth support would come for free as then the credentials can be retrieved just for basic authentication. Some kind of hook or trigger to call renewal functions would be needed though so that tokens can be refreshed transparently or manually if the user needs to re-authenticate. >> (Then, extremely ideally, the FSF could work out legal agreements with >> the various OAuth providers to get Emacs registered as an OAuth >> application, like, e.g., Thunderbird.) >> > > That would be the best for the end user. Imagine a Gnus user could just > add a new account and on launch Gnus the default browser will open the > login page (or be prompted an URL to visit), which then normally handles > all the login shenanigans (2FA, authenticator, etc.) and viola, you're > logged in. > To allow seamless authentication the FSF could make things much smoother by registering Emacs with common providers, working with FSFE together in this regard could help too (there are other countries than the U.S.). The issue I see is that registering Emacs is not enough since Emacs is in this context merely a runtime for these modes that want to use OAuth. The scope of the permissions they need varies, so their names etc.