Re: Gmail OAuth2 in git send-email

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 3, 2021, 08:28 UTC
Message-ID: <878s3r73g3.fsf@evledraar.gmail.com>
In-Reply-To: <YLhx7nIptHUwXfBD@google.com>

On Wed, Jun 02 2021, Jonathan Nieder wrote:

Show 30 quoted lines

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