GNU bug report logs - #72992
29.4; towards xoauth2 support in Emacs

Previous Next

Package: emacs;

Reported by: Xiyue Deng <manphiz <at> gmail.com>

Date: Tue, 3 Sep 2024 00:00:02 UTC

Severity: wishlist

Found in version 29.4

Full log


View this message in rfc822 format

From: Xiyue Deng <manphiz <at> gmail.com>
To: Andrew Cohen <acohen <at> ust.hk>
Cc: Ted Zlatanov <tzz <at> lifelogs.com>, Philip Kaludercic <philipk <at> posteo.net>, 72992 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#72992: 29.4; towards xoauth2 support in Emacs
Date: Thu, 03 Oct 2024 15:41:34 -0700
Xiyue Deng <manphiz <at> gmail.com> writes:

> Andrew Cohen <acohen <at> ust.hk> writes:
>
> [...]
>
>> 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!
>

Just want to follow up on this: may we try your fixes and maybe try to
contribute for committing upstream?  Also, for the :secret in closures,
do you suggest to remove it or is there another up-to-date way to hide
it in memory?

>>     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.
>

In this regard, is it desirable to make `auth-source-search-backends' a
defgeneric acting on a given protocol (basic vs. xoauth2 vs. others),
and similarly for `nnimap-login' et al.?

>> [...]
>>

-- 
Xiyue Deng




This bug report was last modified 318 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.