Re: gmail+imap+smtp (oauth2)

[Tim Cross]

Cesar Crusius <cesar.crusius@gmail.com> writes:

> [[PGP Signed Part:Undecided]]
> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> Hi
>>
>> I am forced to use gmail at my university (the features google offer are
>> a bit different to the personal accounts)
>> and also for some private stuff.
>>
>> There was a discussion in 2022 about the following issue, but then
>> google dropped this subject because of Covid, however now it seems to
>> back:
>>
>> Now google keeps sending me message that from 30th of May 3rd party
>> packages cannot connect anymore to imap+smtp via the traditional way.
>>
>> It is my understanding that it might be possible make emacs (gnus) work
>> with gmail under those circumstances, that is using oauth2.
>>
>> Has anybody got that to work?
>>
>> If so, can he/she share its setting?
>
> Google seems to be clamping down on OAuth access methods and those of us using
> it to access GMail have been getting a message that our OAuth clients will be
> blocked starting October 3rd. This is because we're using "out of bound 
> OAuth2".
> From what I can tell, the packages need to be rewritten to be "compliant," and
> from what I remember from previous discussions, making them compliant may be a
> non-trivial task involving registering an "official" application and so on.

>From what I recall from previous discussions, the issue centres around
Google's T&C and interpretation of those terms & conditions. 

Google requires that apps using oauth2 to access their services be
approved by them and assigned an application ID. The problem is that the
T&C require that the oauth2 tokens must be kept secret. However, this is an
issue because you cannot have both open source code and a secret
applicaiton ID token embedded in the source code.

It has been suggested by some that this is a misintgerpretation of the
T&C and that the application ID is possibly not one of the toekns which
must remain secret (in which case, it could be embedded in the code).
Attempts to get clarification on this point from Google have failed to
get a response. This is possibly something the FSF could assist with. In
particular, they could get the necessary clarification and if there is a
problem, clearly articulate the issues to Google and ask them what their
plans/solution is for open source applications. (at this point, I
suspect their solution is application passwords).