From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Xiyue Deng Newsgroups: gmane.emacs.bugs Subject: bug#72992: 29.4; towards xoauth2 support in Emacs Date: Thu, 19 Sep 2024 15:37:30 -0700 Message-ID: <878qvnmfrp.fsf@debian-hx90.lan> References: <87h6ayfo87.fsf_-_@debian-hx90.lan> <877cb8oihg.fsf@debian-hx90.lan> <878qvocjkz.fsf@ust.hk> <87ldzom4rz.fsf@debian-hx90.lan> <87zfo4au81.fsf@ust.hk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27570"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Notmuch/0.38.3 (https://notmuchmail.org) Emacs/29.4 (x86_64-pc-linux-gnu) Cc: Ted Zlatanov , Philip Kaludercic , 72992@debbugs.gnu.org, Stefan Kangas To: Andrew Cohen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 20 00:39:16 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 1srPnw-0006zb-3p for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Sep 2024 00:39:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1srPnT-00045T-Uz; Thu, 19 Sep 2024 18:38:48 -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 1srPnQ-00045A-Uz for bug-gnu-emacs@gnu.org; Thu, 19 Sep 2024 18:38: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 1srPnQ-00028O-Lv for bug-gnu-emacs@gnu.org; Thu, 19 Sep 2024 18:38: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=UaED+pT8lX74EqvaMpnQXeBLHkq1Qg/QX/Yfvsxdq3U=; b=Ja1APqF1g4MYuLCAjMPRr8Ql6dj3RcStNmxwsUCEE7IqeQHN2+t8kXTuJ3IIJt9wNDn6C07IIvYvKz6lAOHGbSZuW/d7XeljV5gkE4pshvFEQXStp9ecDICv5BQoGTI6zVP7Li1FU+0KmA/+dPO7EMMoTkzVIIjrl5cpHDgiMjuIvZcEWd6zCzG2WOJ5+KdkeKvQGi3vQZwH12f0+Ey1Xk5VUU0kXa9afO31uFViXBzG3YOY9DgXPbxfeTrDhUGYLxnM0aLQ1KIPtnEBNCZ9GfRmdtJeFh2tMK7smQnCo4bI3ggqtkQ3xqSxERQRekuDES6MaFtnwf9h7s+3QLfDqw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1srPni-0003i5-Ai for bug-gnu-emacs@gnu.org; Thu, 19 Sep 2024 18:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Xiyue Deng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Sep 2024 22:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72992 X-GNU-PR-Package: emacs Original-Received: via spool by 72992-submit@debbugs.gnu.org id=B72992.172678554114254 (code B ref 72992); Thu, 19 Sep 2024 22:39:02 +0000 Original-Received: (at 72992) by debbugs.gnu.org; 19 Sep 2024 22:39:01 +0000 Original-Received: from localhost ([127.0.0.1]:33612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1srPng-0003hn-Uk for submit@debbugs.gnu.org; Thu, 19 Sep 2024 18:39:01 -0400 Original-Received: from mail-pl1-f176.google.com ([209.85.214.176]:44115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1srPnd-0003hY-QF for 72992@debbugs.gnu.org; Thu, 19 Sep 2024 18:38:59 -0400 Original-Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-208ccde82e6so12122955ad.0 for <72992@debbugs.gnu.org>; Thu, 19 Sep 2024 15:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726785454; x=1727390254; darn=debbugs.gnu.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=UaED+pT8lX74EqvaMpnQXeBLHkq1Qg/QX/Yfvsxdq3U=; b=SVkJ5kp8L2A9nmdBMEF+/OZ+cfkRwBauaElLm8GIJIQq+SBNnBSyNTjMu+3w0CA0sL PrGZ+wmydeeS1YP4+BYeZYNOHwi23larS6xYwv/P65NqRmctJg/J2WSIGii7UJUKZGoH 6eQimQLtZJLRRiKfSwiNIRD6neoeqwRqB/lWZxdm/t8HmusADvE3vfYvRor2gvYrwVDR 1wbCJLRvRlJ8/b4LX9zI4BZGn7dwHczk3Vrf8uptbu/3FI0vAALwNh/JHochMqOO3GYC jnDS6RvnRon0vRtytfnW13GQx0vJBGxOnnC9G0h0/iilZgsqMuIHXBqKjl65T0eQJngP mxtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726785454; x=1727390254; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UaED+pT8lX74EqvaMpnQXeBLHkq1Qg/QX/Yfvsxdq3U=; b=JOGntYIoLlSZzqaj1xLK4CyMm1WkcDjNvG+SHF1CVH1ynX14f1CPg8FGUF/Obl0qfa GpOBcMgljY+9WT28wUyklzjgx2knB3U8BNNcZDDXIX/yswYD5+dQvUv83GsWXBJz27pu gz5wRxtbHNafwfslClKwtT8istojItzbS1We34WPm58WzGsyoB14U23h0XHmQdzb6JJX +pZl4dJoAHsIiRnGwq8Nv+bRlKk0ecKN6qZ+DTrgFi90JvN8HMP5JvkfF0ZsouqqdN+B NwFiiaLn4lIcSvs7yxlzFgJkQubJyXkBsvuiGaBIahLPME9hM4ykD943uv1Z4OO250Lk NXAg== X-Forwarded-Encrypted: i=1; AJvYcCX5oYcnm32br8vWZvvnhbeFTb3aJbRhZwxPDW/b8JQTR1Q+2myKIFQcf1Rqm3SBwOTekLfYKw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyydB5zSznm54AUVs4EjgBCh0lFsUplYHFYShvlm1SiSNG9yhYM mEdM89O64fanEgk0FlESMUevAPm6TfXOKeClQnYCr478WBSl/GbV X-Google-Smtp-Source: AGHT+IF2F4C21QBHy1IjxE6KNzHWR07VWAGwY3mriWJVxAlb5KkrT5BjcP1IdZvrRY2ZjpNoV7sZ+g== X-Received: by 2002:a17:903:2b0d:b0:207:17f6:9efc with SMTP id d9443c01a7336-208d83b95bdmr10921045ad.25.1726785453565; Thu, 19 Sep 2024 15:37:33 -0700 (PDT) Original-Received: from debian-hx90 (syn-076-094-249-045.res.spectrum.com. [76.94.249.45]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-207946d2823sm84889955ad.148.2024.09.19.15.37.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Sep 2024 15:37:33 -0700 (PDT) In-Reply-To: <87zfo4au81.fsf@ust.hk> 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:292078 Archived-At: Andrew Cohen writes: >>>>>> "XD" == Xiyue Deng writes: > > XD> Hi Andrew, Andrew Cohen writes: > > >>>>>>> "XD" == Xiyue Deng writes: > >> > > [...] > > XD> The basic support is actually in the Emacs core already, > XD> e.g. for Gnus nnimap[2] and smtpmail[3]. However, this assumes > XD> one to put the access_token in place of `:secret' in the > XD> auth-source file as Emacs uses password as the access_token in > XD> both places. However, access_token expires quite frequently > XD> (e.g. about 1 hour for Gmail) and without refreshing it > XD> automatically it is practically impossible to use conveniently. > XD> Hence the propose hack and the following suggestion. > >> > >> > >> This isn't actually true. When I added the support many years > >> ago, I updated auth-source so that the :secret field can be a > >> function, and this is how you should be using the current xoauth > >> support. > > XD> Thanks for pointing this out! I found the place where `:secret' > XD> is handled as a function[1]. However, this requires a user to > XD> implement the oauth2 logic oneself, which I'm afraid is a bit > XD> too low-level and error-prone. (Actually, can I actually put a > XD> lisp function in auth-source.gpg?) > > I don't think you have to do anything low level, and I don't think there > is anything error prone here; you can use the functions from oauth > themselves (oauth2.el can create its own plstores, but I prefer to use > auth-source.el to manage the stores). The only things needed are a call > to oauth2-refresh-access to get a new token, and then > oauth2-token-access-token to return the new access token. > Yes, I'm not worried about power users. I just think that the average Emacs user would be hesitant on writing ELisp themselves to enable xoauth2 login (hence low-level), especially when they don't have anything to copy from (yet). Many Gnus users are not programmers and would prefer writing "(nnimap-authenticator 'xoauth2)" and expect it to work. But I believe you don't object providing that convenience OOTB either. > The function I wrote computes the refresh time to decide when to create > a new token. This logic could easily be put into oauth2 instead. > I am planning on adding this to oauth2 as well. Will ask for your review when that happens. > And yes, you can put the lisp function in auth-source.gpg (this is what > I do). > TIL! (I used to have a handwritten script to get the values for offlineimap. Guess we should all be using `auth-info-password') > By the way there are some significant bugs in auth-source.el which I > have fixed in my personal tree but haven't yet pushed. I have so little > time for emacs at the moment, but I'll try to get around to it. And > there is one major deficiency in auth-source.el that I want to deal > with: obfuscation of the :secret. When Ted originally wrote > auth-source.el he wrapped the :secret in a closure so that the secret > itself wasn't visible in memory. At the time he did this, closures > weren't fully part of emacs, and their implementation at the time didn't > expose the contents of the closure in bytecode. But the current official > implementation does, so this obfuscation trick no longer works. I want > to remove it since it no longer works and might lead to confusion. > Looking forward to it! > XD> Maybe auth-source source can host a helper function that checks > XD> if `:secret' is not set and xaouth2 is preferred (e.g. `:auth' > XD> is `xoauth2') and all required credentials are available it will > XD> get the access_token and put it `:secret' (or basically my hacky > XD> advice :) > > I think this isn't the right way to go. Currently xoauth2 is one of > several supported SASL methods. The logic is supposed to be to try them > in a certain order, but this hasn't worked properly for some > time. Nobody has noticed since almost everyone uses only the basic > method. In gnus there has always been a server variable, > nnimap-authenticator, that chooses the preferred sasl method, which is > how the current support for xaouth2 is designed to work. I think this > is the right way to handle this (rather than relying on some specific > form of the auth-source entry) but it would be good to fix the logic in > nnimap.el to allow multiple methods to be tried. > Right. The `:auth' trick I did is just to workaround the restriction that `nnimap-login' chooses basic method over other methods, and I'd prefer a better built-in support in auth-source myself. As you mentioned, maybe it can be remodeled after `smtpmail-try-auth-method' to so that the login method is chosen on demand instead of trial-and-error. > [...] > > XD> P.S. Is your set up mentioned in Bug#72358 still working for > XD> outlook.com emails? After reaching out to an MS representative > XD> they mentioned that token refresh was disabled[3] for > XD> outlook.com so I just gave up. Maybe it still works for Outlook > XD> Org emails? > > Yes, it still works perfectly. I suspect that the information they gave > you isn't fully accurate :) Thanks for confirming! I'll follow-up in private to try to figure this out if you don't mind. > -- > Andrew Cohen -- Xiyue Deng