Re: [PATCH] b4: allow using xoauth2/bearer token to authenticate to SMTP servers

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Tomas,

On Tue, Mar 10, 2026 at 08:48:55AM +0200, Tomas Melin wrote:
> Hi,
> 
> On 09/03/2026 19:13, Dmitry Torokhov wrote:
> > On Mon, Mar 09, 2026 at 11:50:40AM +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 09/03/2026 09:49, Dmitry Torokhov wrote:
> > > > 
> > > In your case, how do you provide the new token to git credential?
> > git credential itself calls into configured helpers and the helper does
> > this. You do not need to replicate this logic in other places.
> > 
> > > How does you .gitconfig for this look like?
> > global  sendemail.smtpserver smtp.gmail.com
> > global  sendemail.smtpserverport 587
> > global  sendemail.smtpencryption tls
> > global  sendemail.smtpuser dmitry.torokhov@gmail.com
> > global  sendemail.thread true
> > global  sendemail.bcc dmitry.torokhov@gmail.com
> > global  sendemail.suppresscc self
> > global  credential.helper cache --timeout=3000
> > global  credential.helper local-helper
> > local   sendemail.smtpuser dmitry.torokhov@gmail.com
> > local   sendemail.smtpauth XOAUTH2
> > local   sendemail.bcc dmitry.torokhov@gmail.com
> > 
> > The local-helper is a custom python script that behaves similarly to the
> > gmail credential helper, but the difference that it supports different
> > credential stores - either based on secret storage API or GPG-based so I
> > can move my configuration between a headless workstation, a VM, or my
> > laptop easily.
> > 
> > The beauty of credential helpers is that if they do not know how to
> > handle the request they simply skip it so that the next one might be
> > able to resolve it.
> 
> Yes, indeed then this looks like a cleaner solution to the authentication
> process and
> 
> the approach proposed in your patch should be taken instead of my initial
> attempt.
> 
> FWIW I tested this out, but for some reason I was occasionally not getting
> the
> 
> token back, instead it falls back to password authentication prompt (which
> then fails).


Hmm, this is weird. I've had the setup with the "git credential", my
credential helper, and "git send-email" for the last few years and I did
not observe this issue... Maybe one of the helpers is flaky? You can
call "git credential" from a script like this to test:


#!/bin/bash
#
git credential fill << ENDOFDATA | sed -n 's/^password=\(.*\)/\1/ p'
protocol=smtp
host=gmail.com
username=${1}
ENDOFDATA

to see how reliable it is. Obviously adjust host and other details as
needed.

Thanks.

-- 
Dmitry