Gmail OAuth2 in git send-email

Hi,

For most email providers, adding following .gitconfig is enough to 
seamlessly use git send-email:

           [sendemail]
                   smtpEncryption = tls
                   smtpServer = <server>
                   smtpUser = <email>
                   smtpServerPort = 587

But for users that use Gmail (like me), we must either enable 2FA and 
generate app-specific password for use with git send-email, or enable 
less-secure app access. That's because Gmail prefers authenticating with 
OAuth2, but git send-email use plain text authentication instead.

I personally prefer the latter because I know that I enabled less-secure 
app access only for duration of sending patches with git send-email 
(that is, I switched the trigger when I run git send-email).

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.

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 (even don't 
have any of required payment methods), whereas the latter approach we 
must cover that cost (and Software Freedom Conservancy can raise funds 
needed for it or git.git developers can pay it).

Thanks.

[1]: https://developers.google.com/workspace/guides/create-project

-- 
An old man doll... just what I always wanted! - Clara

Hi,

Bagas Sanjaya [off-list ref] 于2021年6月3日周四 下午1:05写道：

Hi,

For most email providers, adding following .gitconfig is enough to
seamlessly use git send-email:

quoted

           [sendemail]
                   smtpEncryption = tls
                   smtpServer = <server>
                   smtpUser = <email>
                   smtpServerPort = 587

But for users that use Gmail (like me), we must either enable 2FA and
generate app-specific password for use with git send-email, or enable
less-secure app access. That's because Gmail prefers authenticating with
OAuth2, but git send-email use plain text authentication instead.

I personally prefer the latter because I know that I enabled less-secure
app access only for duration of sending patches with git send-email
(that is, I switched the trigger when I run git send-email).

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.

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 (even don't
have any of required payment methods), whereas the latter approach we
must cover that cost (and Software Freedom Conservancy can raise funds
needed for it or git.git developers can pay it).

I met the same question as you before. [1] (write by chinese)
We need cumbersome operations to allow gmail to agree to use git send-email.
I also want to know if send-email can be made more convenient
(to reduce some configuration problems with gmail).

[1]: https://adlternative.github.io/archlinux%E4%B8%8A%E7%9A%84git-send-email%E9%97%AE%E9%A2%98%E7%9A%84%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88/

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.

Thanks and hope that helps,
Jonathan

[1] https://bugs.debian.org/905551;msg=5
[2] https://www.chromium.org/developers/how-tos/api-keys

On Thu, Jun 3, 2021 at 2:09 AM Jonathan Nieder [off-list ref] wrote:

Bagas Sanjaya wrote:

quoted

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.
[1] https://bugs.debian.org/905551;msg=5

That link leads to a "no results" page. This link seems to work:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905551

On Wed, Jun 02 2021, Jonathan Nieder wrote:

Hi,

Bagas Sanjaya wrote:

quoted

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.

quoted

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

Ævar Arnfjörð Bjarmason wrote:

On Wed, Jun 02 2021, Jonathan Nieder wrote:

quoted

Bagas Sanjaya wrote:

quoted

quoted

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.

quoted

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.

If Google requires a client secret, then it can't be used with open
source applications. Period.

Sure, you could create a developer account, create an app, get a client
id and secret, put into your authentication script, and the finally do
the authentication.

Open a browser with the link, type your password, verify on your phone
with a 2FA app or whatever.

And finally you'll get a token. Which will have to be refreshed
regularly.


Or you can just create an app password.

Cheers.

-- 
Felipe Contreras

On Thu, Jun 03, 2021 at 12:02:08PM +0700, Bagas Sanjaya wrote:

But for users that use Gmail (like me), we must either enable 2FA and
generate app-specific password for use with git send-email

Is there a general problem with this approach? Gmail has been my
recommendation for everyone needing a free email account -- it's still
possible to configure it to be perfectly usable with patch-based workflows,
even if it has its own ideas about web ui treading.

The fact that Gmail forces folks to enable 2fa for app passwords is an added
bonus in my book. :)

There are other alternatives, but they are not gratis or don't work well for
sending patches. I'm also aware that gmail is not reliable for certain
geographical locales, so it's not a solution that suits everyone. We have
recently partnered with migadu.com and will start providing email accounts for
Linux devs who cannot reliably use any other solution either due to their
employer doing nasty things to outgoing mail, or some other reason. At $20 a
year, migadu's pricing is hard to beat, though I know it's not for everyone.

-K

On Thu, Jun 3, 2021 at 2:09 PM Konstantin Ryabitsev
[off-list ref] wrote:

On Thu, Jun 03, 2021 at 12:02:08PM +0700, Bagas Sanjaya wrote:

quoted

But for users that use Gmail (like me), we must either enable 2FA and
generate app-specific password for use with git send-email

Is there a general problem with this approach? Gmail has been my
recommendation for everyone needing a free email account -- it's still
possible to configure it to be perfectly usable with patch-based workflows,
even if it has its own ideas about web ui treading.

The fact that Gmail forces folks to enable 2fa for app passwords is an added
bonus in my book. :)

The 2fa requirement is a problem for those of us who don't have
smartphones or SMS. (I see now that they also offer 8-digit backup
codes to print out for 2fa; perhaps that might be a workable option,
though I haven't tested it.)

On Thu, Jun 03, 2021 at 02:25:42PM -0400, Eric Sunshine wrote:

quoted

The fact that Gmail forces folks to enable 2fa for app passwords is an added
bonus in my book. :)

The 2fa requirement is a problem for those of us who don't have
smartphones or SMS. (I see now that they also offer 8-digit backup
codes to print out for 2fa; perhaps that might be a workable option,
though I haven't tested it.)

I'm not going to argue too much, but I'd say that someone who's looking for
solution to use with git-send-email is *likely* going to have access to a
smartphone. :)

It's also possible to use TOTP without a smartphone (e.g. via a desktop app),
though this would largely defeat the purpose.

-K

On Thu, Jun 03, 2021 at 02:32:20PM -0400, Konstantin Ryabitsev wrote:

On Thu, Jun 03, 2021 at 02:25:42PM -0400, Eric Sunshine wrote:

quoted

quoted

The fact that Gmail forces folks to enable 2fa for app passwords is an added
bonus in my book. :)

The 2fa requirement is a problem for those of us who don't have
smartphones or SMS. (I see now that they also offer 8-digit backup
codes to print out for 2fa; perhaps that might be a workable option,
though I haven't tested it.)

I'm not going to argue too much, but I'd say that someone who's looking for
solution to use with git-send-email is *likely* going to have access to a
smartphone. :)

I do have a smartphone. Due to the battery life of smartphones I don't
have access to it most of the time.

It's also possible to use TOTP without a smartphone (e.g. via a desktop app),
though this would largely defeat the purpose.

There are also TOTP hardware tokens but I haven't tried one. I think
that the U2F tokens are better supported anyway.

If you want some sort of real security I would avoid smartphones and go
for hardware tokens. If you want to fulfill arbitrary requiremens
workarounds that emulate a smartphone well enough exist. For TOTP you
don't even need an emulator, only a QR code reader (in case the site
insists on using QR code and does not show the plaintext) and a desktop
TOTP application.

Thanks

Michal

Eric Sunshine wrote:

On Thu, Jun 3, 2021 at 2:09 PM Konstantin Ryabitsev
[off-list ref] wrote:

quoted

On Thu, Jun 03, 2021 at 12:02:08PM +0700, Bagas Sanjaya wrote:

quoted

But for users that use Gmail (like me), we must either enable 2FA and
generate app-specific password for use with git send-email

Is there a general problem with this approach? Gmail has been my
recommendation for everyone needing a free email account -- it's still
possible to configure it to be perfectly usable with patch-based workflows,
even if it has its own ideas about web ui treading.

The fact that Gmail forces folks to enable 2fa for app passwords is an added
bonus in my book. :)

The 2fa requirement is a problem for those of us who don't have
smartphones or SMS.

You don't need either of those with an app password:

  https://support.google.com/mail/answer/185833/sign-in-using-app-passwords

And of course you don't need them for the second step authentication
either, you can use any OTP client:

  https://github.com/paolostivanin/OTPClient

Cheers.

-- 
Felipe Contreras

On Thu, Jun 03, 2021 at 09:02:31PM +0200, Michal Suchánek wrote:

quoted

I'm not going to argue too much, but I'd say that someone who's looking for
solution to use with git-send-email is *likely* going to have access to a
smartphone. :)

I do have a smartphone. Due to the battery life of smartphones I don't
have access to it most of the time.

As a note, you wouldn't need to use it "all the time" -- just for the initial
login via the browser. Once it's done and you set up the app passwords for
SMTP/IMAP access, you would rarely ever need to access the TOTP token again.

-K

On Thu, Jun 03, 2021 at 03:07:56PM -0400, Konstantin Ryabitsev wrote:

On Thu, Jun 03, 2021 at 09:02:31PM +0200, Michal Suchánek wrote:

quoted

quoted

I'm not going to argue too much, but I'd say that someone who's looking for
solution to use with git-send-email is *likely* going to have access to a
smartphone. :)

I do have a smartphone. Due to the battery life of smartphones I don't
have access to it most of the time.

As a note, you wouldn't need to use it "all the time" -- just for the initial
login via the browser. Once it's done and you set up the app passwords for
SMTP/IMAP access, you would rarely ever need to access the TOTP token again.

I also avoid doing anything security sensitive on the smartphone. They
tend to run old vulnerable software because smarphonde vendors aren't
agile with fixes, and they are a rewarding target for hackers.

Given that your smartphone and our PC are typically connected to the
same network it is not difficult to correlate the two.

Thanks

Michal

On Thu, Jun 3, 2021 at 3:06 PM Felipe Contreras
[off-list ref] wrote:

Eric Sunshine wrote:

quoted

The 2fa requirement is a problem for those of us who don't have
smartphones or SMS.

You don't need either of those with an app password:

  https://support.google.com/mail/answer/185833/sign-in-using-app-passwords

Google requires 2fa to be enabled in order to create app passwords,
and to enable 2fa requires a phone or a physical security device, so
I'm afraid I don't see how your suggestion is supposed to work for
people lacking such devices.

And of course you don't need them for the second step authentication
either, you can use any OTP client:

  https://github.com/paolostivanin/OTPClient

Thanks, that's an interesting bit of information, though if a person
can't enable 2fa in the first place, then... (intentionally left
blank)

On Thu, Jun 3, 2021 at 3:08 PM Konstantin Ryabitsev
[off-list ref] wrote:

As a note, you wouldn't need to use it "all the time" -- just for the initial
login via the browser. Once it's done and you set up the app passwords for
SMTP/IMAP access, you would rarely ever need to access the TOTP token again.

Thanks, that's a helpful datapoint. Coupled with Felipe's tidbit about
PC-based OTP clients, it sounds like this might almost be usable for
someone without a phone (assuming 2fa can somehow be enabled).

Eric Sunshine wrote:

Google requires 2fa to be enabled in order to create app passwords,

That doesn't make sense.

It's like complaining that you need to lose a limb in order to use
prostetics...

App passwords are a suboptimal solution in case you cannot use 2fa for a
certain application.

If you cannot use 2fa for any application, then don't enable 2fa, and
then you don't need an app password. Just use your regular password.

quoted

And of course you don't need them for the second step authentication
either, you can use any OTP client:

  https://github.com/paolostivanin/OTPClient

Thanks, that's an interesting bit of information, though if a person
can't enable 2fa in the first place, then... (intentionally left
blank)

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

Cheers.

-- 
Felipe Contreras

Hi,

Ævar Arnfjörð Bjarmason wrote:

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.

Yes, that's what I do.

[...]

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

I agree that it wouldn't be worth "git send-email" registering for its
own API key, mostly because registering for API keys with every email
provider would be a distraction from what git send-email tries to do.

On the other hand, I would mind a perl library or a commandline tool
that git send-email calls having _its_ own API key.  That would be
helpful to other programs that want to send email as well, and it
would help users who are not as patient as we are in trudging through
the multi-step process required.  For example, it's nice that KMail,
Apple's Mail.app, and so on have their own API keys instead of every
user of those programs having to generate their own.

Of course, that's a broader topic than Git; it's not something that we
on the Git list are uniquely positioned to do ourselves.  I only
mention it in case someone in this thread wants to write it.  Then git
send-email could use such a library or point to such a tool in its
documentation.

Thanks,
Jonathan

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

Eric Sunshine wrote:

quoted

Google requires 2fa to be enabled in order to create app passwords,

That doesn't make sense.

It's like complaining that you need to lose a limb in order to use
prostetics...

App passwords are a suboptimal solution in case you cannot use 2fa for a
certain application.

If you cannot use 2fa for any application, then don't enable 2fa, and
then you don't need an app password. Just use your regular password.

quoted

quoted

And of course you don't need them for the second step authentication
either, you can use any OTP client:

  https://github.com/paolostivanin/OTPClient

Thanks, that's an interesting bit of information, though if a person
can't enable 2fa in the first place, then... (intentionally left
blank)

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

-- 
Danh

Đoàn Trần Công Danh wrote:

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

quoted

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

Presumably if you don't have a Google account, then don't have a
gmail.com address, and you can't use Gmail.

So why would this thread interest you?

-- 
Felipe Contreras

On 2021-06-03 21:07:24-0500, Felipe Contreras [off-list ref] wrote:

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

quoted

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

Presumably if you don't have a Google account, then don't have a
gmail.com address, and you can't use Gmail.

So why would this thread interest you?

The first point ;)

quoted

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

-- 
Danh

Jonathan Nieder wrote:

I agree that it wouldn't be worth "git send-email" registering for its
own API key, mostly because registering for API keys with every email
provider would be a distraction from what git send-email tries to do.

On the other hand, I would mind a perl library or a commandline tool
that git send-email calls having _its_ own API key.

Ahem --- I *wouldn't* mind a perl library or commandline tool showing
up that does this.  Sorry for the confusion.

                                                     That would be
helpful to other programs that want to send email as well, and it
would help users who are not as patient as we are in trudging through
the multi-step process required.  For example, it's nice that KMail,
Apple's Mail.app, and so on have their own API keys instead of every
user of those programs having to generate their own.

There's a sendgmail tool in
https://github.com/google/gmail-oauth2-tools.  It requires generating
your own API key but I suppose someone could package it up with an API
key for their package if they wish to.

Jonathan

Jonathan Nieder wrote:

Jonathan Nieder wrote:

quoted

                                                     That would be
helpful to other programs that want to send email as well, and it
would help users who are not as patient as we are in trudging through
the multi-step process required.  For example, it's nice that KMail,
Apple's Mail.app, and so on have their own API keys instead of every
user of those programs having to generate their own.

There's a sendgmail tool in
https://github.com/google/gmail-oauth2-tools.  It requires generating
your own API key but I suppose someone could package it up with an API
key for their package if they wish to.

API keys and client secrets are supposed to be *secret*. You must not
generate *public* packages with them.

I don't know why people insist on using something that isn't supposed to
be used.

If you want to use a 2FA-enabled account with git, then generate an app
password, and use that.

Cheers.

-- 
Felipe Contreras

Đoàn Trần Công Danh wrote:

On 2021-06-03 21:07:24-0500, Felipe Contreras [off-list ref] wrote:

quoted

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

quoted

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

Presumably if you don't have a Google account, then don't have a
gmail.com address, and you can't use Gmail.

So why would this thread interest you?

The first point ;)

Which is?

-- 
Felipe Contreras

On Thu, Jun 3, 2021 at 9:11 PM Felipe Contreras
[off-list ref] wrote:

Eric Sunshine wrote:

quoted

Google requires 2fa to be enabled in order to create app passwords,

That doesn't make sense.

What doesn't make sense? My statement? Or Google's requirements?

It's like complaining that you need to lose a limb in order to use
prostetics...
App passwords are a suboptimal solution in case you cannot use 2fa for a
certain application.

Nevertheless, that's what Google requires.

If you cannot use 2fa for any application, then don't enable 2fa, and
then you don't need an app password. Just use your regular password.

Google has been clamping down on "regular password" use for
third-party applications/sign-ins for several years now and they
heavily discourage it. It is still possible to do it, though, by
enabling "Less secure apps" explicitly[1]. However, when "Less secure
apps" is enabled, they regularly send messages "strongly suggesting"
turning it off. I won't be surprised if the "Less secure apps" option
disappears at some point.

quoted

Thanks, that's an interesting bit of information, though if a person
can't enable 2fa in the first place, then... (intentionally left
blank)

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

I'd be happy to see concrete instructions explaining how to accomplish
all of this since each time I attempted it, Google's instructions led
me in endless circles, with each cycle always asking for (er,
requiring) my non-existent phone number.

[1]: https://support.google.com/accounts/answer/6010255/less-secure-apps-amp-your-google-account

On 2021-06-03 22:45:22-0500, Felipe Contreras [off-list ref] wrote:

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 21:07:24-0500, Felipe Contreras [off-list ref] wrote:

quoted

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

quoted

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

Presumably if you don't have a Google account, then don't have a
gmail.com address, and you can't use Gmail.

So why would this thread interest you?

The first point ;)

Which is?

Which is the point I specificly copy-pasted after that comment,
and it's also the point you stripped out.

I guess it's my bad that I wasn't very clear in the original comment.
So, here is the quote:

quoted

quoted

quoted

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

-- 
Danh

Eric Sunshine wrote:

On Thu, Jun 3, 2021 at 9:11 PM Felipe Contreras
[off-list ref] wrote:

quoted

Eric Sunshine wrote:

quoted

Google requires 2fa to be enabled in order to create app passwords,

That doesn't make sense.

What doesn't make sense? My statement?

Your statement.

quoted

It's like complaining that you need to lose a limb in order to use
prostetics...
App passwords are a suboptimal solution in case you cannot use 2fa for a
certain application.

Nevertheless, that's what Google requires.

No. Google doesn't require app passwords, nor 2fa.

quoted

If you cannot use 2fa for any application, then don't enable 2fa, and
then you don't need an app password. Just use your regular password.

Google has been clamping down on "regular password" use for
third-party applications/sign-ins for several years now and they
heavily discourage it.

Perhaps, but they don't requier 2fa. If you don't want to use 2fa, then
use regular passwords.

Or just don't use Gmail.

-- 
Felipe Contreras

Đoàn Trần Công Danh wrote:

On 2021-06-03 22:45:22-0500, Felipe Contreras [off-list ref] wrote:

quoted

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 21:07:24-0500, Felipe Contreras [off-list ref] wrote:

quoted

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-03 20:11:45-0500, Felipe Contreras [off-list ref] wrote:

quoted

All you need to enable 2fa is demonstrate that you can *use* 2fa... So
you need an OTP client.

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I tried to create a new Google account to double check my memory,
Google now requires a phone number in order to *create* new Google
accounts.

Presumably if you don't have a Google account, then don't have a
gmail.com address, and you can't use Gmail.

So why would this thread interest you?

The first point ;)

Which is?

Which is the point I specificly copy-pasted after that comment,
and it's also the point you stripped out.

I guess it's my bad that I wasn't very clear in the original comment.
So, here is the quote:

quoted

quoted

quoted

quoted

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I still don't see what is your point.

If you don't have a Gmail account, then why do you care about particular
ways to authenticate into a Gmail account?

-- 
Felipe Contreras

On 2021-06-04 01:00:26-0500, Felipe Contreras [off-list ref] wrote:

Đoàn Trần Công Danh wrote:

quoted

quoted

quoted

quoted

quoted

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I still don't see what is your point.

If you don't have a Gmail account, then why do you care about particular
ways to authenticate into a Gmail account?

I have a GMail account, and I have 2 FA enabled already.

I was talking about my experience when I first enabled 2FA,

Google required me to provide me a phone number, which I hadn't
provided prior to that point.

So, someone else, who haven't enable 2FA and haven't provided Google
phone number, may hesitate to enable 2FA.

The second point is me trying to validate my (usually bad) memory.

-- 
Danh

Đoàn Trần Công Danh wrote:

On 2021-06-04 01:00:26-0500, Felipe Contreras [off-list ref] wrote:

quoted

Đoàn Trần Công Danh wrote:

quoted

quoted

quoted

quoted

quoted

In the past, when I tried to enable 2FA, Google always asks for my
Phone Number because of *security* and *safety* reason.

I still don't see what is your point.

If you don't have a Gmail account, then why do you care about particular
ways to authenticate into a Gmail account?

I have a GMail account, and I have 2 FA enabled already.

I was talking about my experience when I first enabled 2FA,

OK, but I was talking about ways to authenticate into your existing
Gmail account, which was supposed to be the topic of this thread.

Cheers.

-- 
Felipe Contreras