Re: Gmail OAuth2 in git send-email

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 02 2021, Jonathan Nieder wrote:

> Hi,
>
> Bagas Sanjaya wrote:
>
>> We wonder whether git send-email can support Gmail OAuth2 so that we can
>> seamlessly send patches without having to choose either action. But however,
>> we have to create a GCP project [1] first in order to enable Gmail API. This
>> can be overkill for some folks, but unfortunately that's the only way.
>
> Yes, that's how I have mutt and other tools working with my Gmail
> account set up.  See [1] for details.
>
>> If we want to enable support for Gmail OAuth2, should we hands-off API
>> configuration to git send-email users, or should we configure it on behalf
>> of them? Note that when we go the former approach, some Gmail users simply
>> can't afford GCP pricing for whatever reason
>
> I didn't have to pay for GCP in order to set this up; I only had to
> follow the instructions at
> https://developers.google.com/identity/protocols/oauth2 to create a
> client ID and client secret for oauth access.
>
> Alas, I don't think Git can provide its own client secret to do this
> out of the box.  I could imagine Git providing a way to supply an API
> key at build time, but distros would need to go through a procedure
> similar to [2] to make use of it for their own builds.  If someone
> wants to set that up, I think that would make sense as its _own_
> separate package --- e.g. a "sendgmail" command that "git send-email"
> could use via the --sendmail-cmd option.  That way, it would be useful
> for a variety of calling programs and not just Git.

It's been a while but I set this up at some point, why would git or
distros need to make/register a private key? Last I checked you can take
software like git-send-email or whatever, and just register a new
"jonathan's e-mail sending script" with Google's OAuth thingy.

That "jonathan's e-mail sending script" happens to be git-send-email
with a bit of configuration isn't something they know or care about.

That seems like a much better approach than some centralized solution,
since as you note doing that will require some authority to manage keys
etc, and presumably if "jonathan's e-mail sending script" inadvertently
starts using git-send-email.perl to send spam, that would currently not
result in ban on "ævar's e-mail sending script", but if the two were
registered as the same application Google might overzelously ban those
as two tenticles of the same misbehaving "app".