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