Making GNUS continue to work with Gmail

Making GNUS continue to work with Gmail

[Richard Stallman]

To keep GNUS working with Gmail, we need to talk with the developers
of Kmail about how they did it.  But I have no contact with them.

Would someone please volunteer to find them and ask them to talk with
us and give us advice?

If you succeed in finding someone ready, willing and able to advise
us, please put per in touch with me and Lars Ingebrigtsen
<larsi@gnus.org> by email.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[황병희]

Richard Stallman <rms@gnu.org> writes:

> To keep GNUS working with Gmail, we need to talk with the developers
> of Kmail about how they did it.  But I have no contact with them.
>
> Would someone please volunteer to find them and ask them to talk with
> us and give us advice?
>
> If you succeed in finding someone ready, willing and able to advise
> us, please put per in touch with me and Lars Ingebrigtsen
> <larsi@gnus.org> by email.

For many Gnus fan, i just attach related PR:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41386

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

soyeomul@doraji.xyz (황병희) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> To keep GNUS working with Gmail, we need to talk with the developers
>> of Kmail about how they did it.  But I have no contact with them.
>>
>> Would someone please volunteer to find them and ask them to talk with
>> us and give us advice?
>>
>> If you succeed in finding someone ready, willing and able to advise
>> us, please put per in touch with me and Lars Ingebrigtsen
>> <larsi@gnus.org> by email.
>
> For many Gnus fan, i just attach related PR:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41386

The person you want to reach out to is probably dvratil@kde.org. Here's a relevant blog post from him, about how he fixed the Kontact Oauth2 problem:

https://www.dvratil.cz/2019/08/kontact-google-integration-issue/

This hints at having services/app registered with Google, as mentioned in the bug above.

My auth-source-xoauth2 package "avoids" that by having every user do the API key dance with Google, and as a result is rather hard to setup.

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Thu, 06 Aug 2020 10:08:11 -0700, Cesar Crusius <cesar.crusius@gmail.com> said:
    Cesar> My auth-source-xoauth2 package "avoids" that by having every user do
    Cesar> the API key dance with Google, and as a result is rather hard to
    Cesar> setup.

The nnredit package automates this by using a python script to get you
to do the appropriate magic on reddit.com (from memory it fires up a
browser and you just log in once). Perhaps that could be adapted to
auth-source-xoauth2? (no, Iʼm not volunteering)

Robert

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 06 Aug 2020 10:08:11 -0700, Cesar Crusius <cesar.crusius@gmail.com> said:
>     Cesar> My auth-source-xoauth2 package "avoids" that by having every user do
>     Cesar> the API key dance with Google, and as a result is rather hard to
>     Cesar> setup.
>
> The nnredit package automates this by using a python script to get you
> to do the appropriate magic on reddit.com (from memory it fires up a
> browser and you just log in once). Perhaps that could be adapted to
> auth-source-xoauth2? (no, Iʼm not volunteering)

I believe reddit's app registration mechanism is simple enough that you can semi-automate it. In Google's case (as you can see from the the auth-source-xoauth2 package) the whole thing is quite involved indeed.

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The person you want to reach out to is probably dvratil@kde.org. Here's a relevant blog post from him, about how he fixed the Kontact Oauth2 problem:

  > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/

Lars, is this something you can do?

  > My auth-source-xoauth2 package "avoids" that by having every user
  > do the API key dance with Google, and as a result is rather hard
  > to setup.

Aside from the inconvenience, is there anything about this we simply
cannot ask users to do?  Does it require accepting terms that are
unjust and not required for using Gmail itself?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > The person you want to reach out to is probably
>   > dvratil@kde.org. Here's a relevant blog post from him, about how
>   > he fixed the Kontact Oauth2 problem:
>
>   > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
>
> Lars, is this something you can do?
>
>   > My auth-source-xoauth2 package "avoids" that by having every user
>   > do the API key dance with Google, and as a result is rather hard
>   > to setup.
>
> Aside from the inconvenience, is there anything about this we simply
> cannot ask users to do?  Does it require accepting terms that are
> unjust and not required for using Gmail itself?

I went through the process a long time ago, so I can't answer that with certainty. The current legalese is in the pages here:

https://developers.google.com/terms

Somebody with a keener legal eye could look at it, but there are certainly more/different terms there.

As an aside, it is worth noting that my package is not Gmail-specific. It could be used for the Reddit example given before via similar means: register a project/app in Reddit, get the keys, etc.

The crux here is that there needs to be an app - their intent is that the software producer (in this case an "Emacs" or "Gnus") registers an "official" app, and the app manages its secrets in a way compliant with their terms (which we already know is pretty hard for OSS projects).

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[Michael Anckaert]

Cesar Crusius writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > The person you want to reach out to is probably
>>   > dvratil@kde.org. Here's a relevant blog post from him, about how
>>   > he fixed the Kontact Oauth2 problem:
>>
>>   > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
>>
>> Lars, is this something you can do?
>>
>>   > My auth-source-xoauth2 package "avoids" that by having every user
>>   > do the API key dance with Google, and as a result is rather hard
>>   > to setup.
>>
>> Aside from the inconvenience, is there anything about this we simply
>> cannot ask users to do?  Does it require accepting terms that are
>> unjust and not required for using Gmail itself?
>
> I went through the process a long time ago, so I can't answer that with certainty. The current legalese is in the pages here:
>
> https://developers.google.com/terms
>
> Somebody with a keener legal eye could look at it, but there are certainly more/different terms there.
>
> As an aside, it is worth noting that my package is not Gmail-specific. It could be used for the Reddit example given before via similar means: register a project/app in Reddit, get the keys, etc.
>
> The crux here is that there needs to be an app - their intent is that the software producer (in this case an "Emacs" or "Gnus") registers an "official" app, and the app manages its secrets in a way compliant with their terms (which we already know is pretty hard for OSS projects).

I've picked up this discussion from the list archives and decided to chime in with some information I have. Since I lack the previous emails in this discussion, please excuse me replying out of sync. 

Including the client ID / secret key in Emacs source code (as Thunderbird does) is bad practice. In addition, I believe there might be some legal / moral issues with registering an FSF application under the Google TOS.

The only suitable alternative would be to have the user register his own Google Cloud Project and use that client ID to run the OAUTH2 flow. This approach differs in that instead of having one client and many users, we have one client for every user. 

In the past I've written a number of software packages for companies that had to make use of Google API's using OAUTH2 authentication. In some cases we couldn't include the client secret in those packages (various departments had their own Google Cloud projects and API usage guidelines). So in essence I had the same issue as what Emacs is facing now.

The solution was to have the software prompt the user to create a specific project on Google Cloud and specify the client secret in the application configuration. A similar approach could be chosen for Emacs so that instead of having a single client ID for Emacs, every user creates his/her own project and configures the client ID in his/her Emacs configuration. Then the OAUTH2 flow has to be run for that 'Emacs application'.

The flow as I once implemented it could be adapted to Emacs as follows:

 * The Emacs documentation specifies the user what type of Google Cloud project has to be created and what client ID / secrets have to be configured.
 * After configuring this information, the user starts an Emacs command (eg M-x retrieve-oauth-credentials)
 * This command starts a local webserver and opens the address in the user's browser
 * The webpage displayed allows the user to start the OAUTH2 flow which redirects to the local webpage with the OAUTH2 token
 * Emacs stores the OAUTH2 token in a suitable location

I would have to check back to some code I have stored to verify the entire flow and make sure I didn't miss anything. But in essence the flow above is what would be required.

If deemed suitable, I'm willing to aid in development of this feature if someone can spend some time mentoring / guiding me on the required steps and correct implementation details. 

-- 
Michael Anckaert
michael.anckaert@sinax.be
+32 474 066 467
https://sinax.be

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]

Michael Anckaert <michael.anckaert@sinax.be> writes:

> Cesar Crusius writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>   > The person you want to reach out to is probably
>>>   > dvratil@kde.org. Here's a relevant blog post from him, about how
>>>   > he fixed the Kontact Oauth2 problem:
>>>
>>>   > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
>>>
>>> Lars, is this something you can do?
>>>
>>>   > My auth-source-xoauth2 package "avoids" that by having every user
>>>   > do the API key dance with Google, and as a result is rather hard
>>>   > to setup.
>>>
>>> Aside from the inconvenience, is there anything about this we simply
>>> cannot ask users to do?  Does it require accepting terms that are
>>> unjust and not required for using Gmail itself?
>>
>> I went through the process a long time ago, so I can't answer that
>> with certainty. The current legalese is in the pages here:
>>
>> https://developers.google.com/terms
>>
>> Somebody with a keener legal eye could look at it, but there are
>> certainly more/different terms there.
>>
>> As an aside, it is worth noting that my package is not
>> Gmail-specific. It could be used for the Reddit example given before
>> via similar means: register a project/app in Reddit, get the keys,
>> etc.
>>
>> The crux here is that there needs to be an app - their intent is
>> that the software producer (in this case an "Emacs" or "Gnus")
>> registers an "official" app, and the app manages its secrets in a
>> way compliant with their terms (which we already know is pretty hard
>> for OSS projects).
>
> I've picked up this discussion from the list archives and decided to
> chime in with some information I have. Since I lack the previous
> emails in this discussion, please excuse me replying out of sync.
>
> Including the client ID / secret key in Emacs source code (as
> Thunderbird does) is bad practice. In addition, I believe there might
> be some legal / moral issues with registering an FSF application under
> the Google TOS.
>
> The only suitable alternative would be to have the user register his
> own Google Cloud Project and use that client ID to run the OAUTH2
> flow. This approach differs in that instead of having one client and
> many users, we have one client for every user.

This is exactly what the auth-source-xoauth2 package asks the user to do, with documentation on how to do it *for Google projects.*

> In the past I've written a number of software packages for companies
> that had to make use of Google API's using OAUTH2 authentication. In
> some cases we couldn't include the client secret in those packages
> (various departments had their own Google Cloud projects and API usage
> guidelines). So in essence I had the same issue as what Emacs is
> facing now.
>
> The solution was to have the software prompt the user to create a
> specific project on Google Cloud and specify the client secret in the
> application configuration. A similar approach could be chosen for
> Emacs so that instead of having a single client ID for Emacs, every
> user creates his/her own project and configures the client ID in
> his/her Emacs configuration. Then the OAUTH2 flow has to be run for
> that 'Emacs application'.
>
> The flow as I once implemented it could be adapted to Emacs as follows:
>
>  * The Emacs documentation specifies the user what type of Google
> Cloud project has to be created and what client ID / secrets have to
> be configured.
>  * After configuring this information, the user starts an Emacs
> command (eg M-x retrieve-oauth-credentials)
>  * This command starts a local webserver and opens the address in the user's browser
>  * The webpage displayed allows the user to start the OAUTH2 flow
> which redirects to the local webpage with the OAUTH2 token
>  * Emacs stores the OAUTH2 token in a suitable location
>
> I would have to check back to some code I have stored to verify the
> entire flow and make sure I didn't miss anything. But in essence the
> flow above is what would be required.
>
> If deemed suitable, I'm willing to aid in development of this feature
> if someone can spend some time mentoring / guiding me on the required
> steps and correct implementation details.

One worry I have about this is that it wold be very Google-specific, as there are other places where this is necessary (Reddit came up as an example) that have a quite different project registration workflow.

The impression I get from all the discussion is that, in the end, OAUTH2 is just extremely OSS-unfriendly, and currently there may be no better solution than simply say "go register a project and generate the keys" in various levels of detail.

My personal take on this is that documentation serves the purpose better, but I'm not against utility functions that guide you through the setup. I know, for example, that the Google Cloud Developer console is *extremely* accessibility-unfriendly, to the point of being unusable (T.V. Raman can correct me here if I'm exaggerating) - the workflow you sketched above would not solve that problem, as the user still has to navigate the Google interface to do things.

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[T.V Raman]

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


Also, as Ceasar points out, different hosting apps vary in this flow.
Twitter uses OAuth2 but is easier to configure -- witness
twittering-mode.

The other wrinkle with the Google Oauth2 flow is that you cannot
complete it without resorting to a full-blown JS-powered Web browser,
i.e. even if we implemented everything on the emacs side, you would
still need to hand a URL to Chrome Or Firefox to get to the screen that
generates the allow/deny button. At that point, you'll get the refresh
token that you'll need to painfully extract and squirrel away somewhere
--- you can then forget about it until at some future point, some
unforeseen accident invalidates your refresh token at which point you
need to go through the whole flow again.


> Michael Anckaert <michael.anckaert@sinax.be> writes:
>
>> Cesar Crusius writes:
>>
>>> Richard Stallman <rms@gnu.org> writes:
>>>
>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>
>>>>   > The person you want to reach out to is probably
>>>>   > dvratil@kde.org. Here's a relevant blog post from him, about how
>>>>   > he fixed the Kontact Oauth2 problem:
>>>>
>>>>   > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
>>>>
>>>> Lars, is this something you can do?
>>>>
>>>>   > My auth-source-xoauth2 package "avoids" that by having every user
>>>>   > do the API key dance with Google, and as a result is rather hard
>>>>   > to setup.
>>>>
>>>> Aside from the inconvenience, is there anything about this we simply
>>>> cannot ask users to do?  Does it require accepting terms that are
>>>> unjust and not required for using Gmail itself?
>>>
>>> I went through the process a long time ago, so I can't answer that
>>> with certainty. The current legalese is in the pages here:
>>>
>>> https://developers.google.com/terms
>>>
>>> Somebody with a keener legal eye could look at it, but there are
>>> certainly more/different terms there.
>>>
>>> As an aside, it is worth noting that my package is not
>>> Gmail-specific. It could be used for the Reddit example given before
>>> via similar means: register a project/app in Reddit, get the keys,
>>> etc.
>>>
>>> The crux here is that there needs to be an app - their intent is
>>> that the software producer (in this case an "Emacs" or "Gnus")
>>> registers an "official" app, and the app manages its secrets in a
>>> way compliant with their terms (which we already know is pretty hard
>>> for OSS projects).
>>
>> I've picked up this discussion from the list archives and decided to
>> chime in with some information I have. Since I lack the previous
>> emails in this discussion, please excuse me replying out of sync.
>>
>> Including the client ID / secret key in Emacs source code (as
>> Thunderbird does) is bad practice. In addition, I believe there might
>> be some legal / moral issues with registering an FSF application under
>> the Google TOS.
>>
>> The only suitable alternative would be to have the user register his
>> own Google Cloud Project and use that client ID to run the OAUTH2
>> flow. This approach differs in that instead of having one client and
>> many users, we have one client for every user.
>
> This is exactly what the auth-source-xoauth2 package asks the user to do, with documentation on how to do it *for Google projects.*
>
>> In the past I've written a number of software packages for companies
>> that had to make use of Google API's using OAUTH2 authentication. In
>> some cases we couldn't include the client secret in those packages
>> (various departments had their own Google Cloud projects and API usage
>> guidelines). So in essence I had the same issue as what Emacs is
>> facing now.
>>
>> The solution was to have the software prompt the user to create a
>> specific project on Google Cloud and specify the client secret in the
>> application configuration. A similar approach could be chosen for
>> Emacs so that instead of having a single client ID for Emacs, every
>> user creates his/her own project and configures the client ID in
>> his/her Emacs configuration. Then the OAUTH2 flow has to be run for
>> that 'Emacs application'.
>>
>> The flow as I once implemented it could be adapted to Emacs as follows:
>>
>>  * The Emacs documentation specifies the user what type of Google
>> Cloud project has to be created and what client ID / secrets have to
>> be configured.
>>  * After configuring this information, the user starts an Emacs
>> command (eg M-x retrieve-oauth-credentials)
>>  * This command starts a local webserver and opens the address in the user's browser
>>  * The webpage displayed allows the user to start the OAUTH2 flow
>> which redirects to the local webpage with the OAUTH2 token
>>  * Emacs stores the OAUTH2 token in a suitable location
>>
>> I would have to check back to some code I have stored to verify the
>> entire flow and make sure I didn't miss anything. But in essence the
>> flow above is what would be required.
>>
>> If deemed suitable, I'm willing to aid in development of this feature
>> if someone can spend some time mentoring / guiding me on the required
>> steps and correct implementation details.
>
> One worry I have about this is that it wold be very Google-specific,
> as there are other places where this is necessary (Reddit came up as
> an example) that have a quite different project registration workflow.
>
> The impression I get from all the discussion is that, in the end,
> OAUTH2 is just extremely OSS-unfriendly, and currently there may be no
> better solution than simply say "go register a project and generate
> the keys" in various levels of detail.
>
> My personal take on this is that documentation serves the purpose
> better, but I'm not against utility functions that guide you through
> the setup. I know, for example, that the Google Cloud Developer
> console is *extremely* accessibility-unfriendly, to the point of being
> unusable (T.V. Raman can correct me here if I'm exaggerating) - the
> workflow you sketched above would not solve that problem, as the user
> still has to navigate the Google interface to do things.

-- 

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Including the client ID / secret key in Emacs source code (as
  > Thunderbird does) is bad practice. In addition, I believe there
  > might be some legal / moral issues with registering an FSF
  > application under the Google TOS.

Who would have to say "I agree"?  Each user?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The flow as I once implemented it could be adapted to Emacs as follows:

  >  * The Emacs documentation specifies the user what type of Google
  >  * Cloud project has to be created and what client ID / secrets
  >  * have to be configured.

  >  * After configuring this information, the user starts an Emacs
  >  * command (eg M-x retrieve-oauth-credentials)

  >  * This command starts a local webserver and opens the address in
  >  * the user's browser

  >  * The webpage displayed allows the user to start the OAUTH2 flow
  >  * which redirects to the local webpage with the OAUTH2 token

Does that web page function using nonfree software?  (Javascript code,
for instance?)  Knowing Google, I suspect that it does.

If so, we cannot distribute that function, or suggest to users that
they use that page, or have code in Emacs which presumes that they do.

This is a fundamental moral principle of the GNU Project: we hold that
running a nonfree program is never a legitimate solution to any
problem.

We cannot impose that principle on anyone, and we do not try; but we
have a duty not to speak in a way that contradicts it.

It might be possible to write free code which talks to that page
using some (perhaps undocumented) API and avoids that issue.
That would be good.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The crux here is that there needs to be an app - their intent is
  > that the software producer (in this case an "Emacs" or "Gnus")
  > registers an "official" app, and the app manages its secrets in a
  > way compliant with their terms (which we already know is pretty
  > hard for [libre] projects).

That is what Google _says_ -- but is it really true?  There is no
chance we can carry out what Google's terms demand -- we have already
determined that.  So forget abuot _those_ terms.

However, the experience of Kmail suggests that they don't try at all
to comply with those termsm, and Google nonetheless tolerates the
use of Kmail.  That is the avenue that might remain for us.



(I replaced the word "OSS" with "libre" when quoting you, to avoid
describing our work with the former term.  We disagree with that idea.
See https://gnu.org/philosophy/open-source-misses-the-point.html.)

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

> To keep GNUS working with Gmail, we need to talk with the developers
> of Kmail about how they did it.  But I have no contact with them.

> Would someone please volunteer to find them and ask them to talk with
> us and give us advice?

> If you succeed in finding someone ready, willing and able to advise
> us, please put per in touch with me and Lars Ingebrigtsen
> <larsi@gnus.org> by email.

I am confused. I use gnus for reading my Gmail account, since my
university switched to it a couple of years ago. It still works. Are you
saying it will stop working in the future?

Or do you refer to their new authentication method, that I don't use,
having set allow connection to unsafe Apps (or something like this).

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Lars Ingebrigtsen]

Uwe Brauer <oub@mat.ucm.es> writes:

> I am confused. I use gnus for reading my Gmail account, since my
> university switched to it a couple of years ago. It still works. Are you
> saying it will stop working in the future?

Yes, Google have said they will discontinue user name/password
authentication over IMAP.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> I am confused. I use gnus for reading my Gmail account, since my
>> university switched to it a couple of years ago. It still works. Are you
>> saying it will stop working in the future?

> Yes, Google have said they will discontinue user name/password
> authentication over IMAP.

Oops, when? This is very serious. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> I am confused. I use gnus for reading my Gmail account, since my
   >> university switched to it a couple of years ago. It still works. Are you
   >> saying it will stop working in the future?

   > Yes, Google have said they will discontinue user name/password
   > authentication over IMAP.

I just googled, could you please provide a link? If I understand you,
this will stop working if you have, less secure apps enabled?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Lars Ingebrigtsen]

Uwe Brauer <oub@mat.ucm.es> writes:

> I just googled, could you please provide a link?

Sorry; don't have one.

> If I understand you, this will stop working if you have, less secure
> apps enabled?

It has nothing to do with security, but, yes, I believe Google calls it
"Allow less secure apps" in their web interface.  That option will go
away.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Sun, 09 Aug 2020 12:36:46 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Uwe Brauer <oub@mat.ucm.es> writes:
    >> I just googled, could you please provide a link?

    Lars> Sorry; don't have one.

    >> If I understand you, this will stop working if you have, less secure
    >> apps enabled?

    Lars> It has nothing to do with security, but, yes, I believe Google calls it
    Lars> "Allow less secure apps" in their web interface.  That option will go
    Lars> away.

for people using gsuite (or whatever the commercial version of
gmail/google docs is called these days). Iʼve not seen any indication
that they intend to do the same for non-commercial gmail access.

Robert

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Sun, 09 Aug 2020 12:57:08 +0200, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Sun, 09 Aug 2020 12:36:46 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
    Lars> Uwe Brauer <oub@mat.ucm.es> writes:
    >>> I just googled, could you please provide a link?

    Lars> Sorry; don't have one.

    >>> If I understand you, this will stop working if you have, less secure
    >>> apps enabled?

    Lars> It has nothing to do with security, but, yes, I believe Google calls it
    Lars> "Allow less secure apps" in their web interface.  That option will go
    Lars> away.

    Robert> for people using gsuite (or whatever the commercial version of
    Robert> gmail/google docs is called these days). Iʼve not seen any indication
    Robert> that they intend to do the same for non-commercial gmail access.

<https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html>

seems to support that

Robert

Re: Making GNUS continue to work with Gmail

[황병희]

Uwe Brauer <oub@mat.ucm.es> writes:

>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>    >> I am confused. I use gnus for reading my Gmail account, since my
>    >> university switched to it a couple of years ago. It still works. Are you
>    >> saying it will stop working in the future?
>
>    > Yes, Google have said they will discontinue user name/password
>    > authentication over IMAP.
>
> I just googled, could you please provide a link? If I understand you,
> this will stop working if you have, less secure apps enabled?

LSA(less secure apps) enabling is not good. Though you would like to
login into Gmail with Emacs/ssmtp/nullmailer/msmtp. The [app password --
16 digit code] is the best choice for now. In my case i did put it(app
password) into /etc/ssmtp/ssmtp-gmail.conf ;;;

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _白衣從軍_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[황병희]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 09 Aug 2020 12:57:08 +0200, Robert Pluim <rpluim@gmail.com> said:
>
>>>>>> On Sun, 09 Aug 2020 12:36:46 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
>     Lars> Uwe Brauer <oub@mat.ucm.es> writes:
>     >>> I just googled, could you please provide a link?
>
>     Lars> Sorry; don't have one.
>
>     >>> If I understand you, this will stop working if you have, less secure
>     >>> apps enabled?
>
>     Lars> It has nothing to do with security, but, yes, I believe Google calls it
>     Lars> "Allow less secure apps" in their web interface.  That option will go
>     Lars> away.
>
>     Robert> for people using gsuite (or whatever the commercial version of
>     Robert> gmail/google docs is called these days). Iʼve not seen any indication
>     Robert> that they intend to do the same for non-commercial gmail access.
>
> <https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html>

Thanks for information Robert^^^
(Just i add the URL into Firefox)

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _白衣從軍_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]


Lars> Uwe Brauer <oub@mat.ucm.es> writes:

Lars> Sorry; don't have one.


Lars> It has nothing to do with security, but, yes, I believe Google calls it
Lars> "Allow less secure apps" in their web interface.  That option will go
Lars> away.

Robert> for people using gsuite (or whatever the commercial version of
Robert> gmail/google docs is called these days). Iʼve not seen any indication
Robert> that they intend to do the same for non-commercial gmail access.

> <https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html>

> seems to support that

Ok, that is good for me, at least for my university account, I have also
a very old gmail account going back to 2004, which also seems
unaffected. But I would not trust it. So yes I think it where good to
have the more recent method of authentication implemented.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 10652 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]


> Uwe Brauer <oub@mat.ucm.es> writes:

> LSA(less secure apps) enabling is not good. Though you would like to
> login into Gmail with Emacs/ssmtp/nullmailer/msmtp. The [app password --
> 16 digit code] is the best choice for now. In my case i did put it(app
> password) into /etc/ssmtp/ssmtp-gmail.conf ;;;

Thanks for this information! But  can you elaborate it a bit? how to do
connect to your gmail account with gnus in this setting?

Thanks 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[황병희]

Uwe Brauer <oub@mat.ucm.es> writes:

>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> LSA(less secure apps) enabling is not good. Though you would like to
>> login into Gmail with Emacs/ssmtp/nullmailer/msmtp. The [app password --
>> 16 digit code] is the best choice for now. In my case i did put it(app
>> password) into /etc/ssmtp/ssmtp-gmail.conf ;;;
>
> Thanks for this information! But  can you elaborate it a bit? how to do
> connect to your gmail account with gnus in this setting?

Just i did replace <user-password> with <app-password> in
/etc/ssmtp/ssmtp-gmail.conf and i did not touch ~/.gnus ;;;

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Yes, Google have said they will discontinue user name/password
  > > authentication over IMAP.

  > Oops, when? This is very serious. 

I have asked for someone to volunteer to get in touch with the Kmail
developers to ask for their advice about how to deal with this.  As
far as I know, nobody has done it.  Would you be willing to write to
them?
 
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

   > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
   > [[[ whether defending the US Constitution against all enemies,     ]]]
   > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   >> > Yes, Google have said they will discontinue user name/password
   >> > authentication over IMAP.

   >> Oops, when? This is very serious. 

   > I have asked for someone to volunteer to get in touch with the Kmail
   > developers to ask for their advice about how to deal with this.  As
   > far as I know, nobody has done it.  Would you be willing to write to
   > them?

Yes, but also two comments:

    1. Do you have a link with an announcement of the gmail developers?

    2. I presume such an advice would be useful for rmail, for which you
       are still the maintainer? (VM wanderlust and others which however
       not part of  Emacs)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Mon, 10 Aug 2020 08:43:19 +0200, Uwe Brauer <oub@mat.ucm.es> said:

    Uwe> Yes, but also two comments:

    Uwe>     1. Do you have a link with an announcement of the gmail developers?

I posted it earlier:

<https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html>

    Uwe>     2. I presume such an advice would be useful for rmail, for which you
    Uwe>        are still the maintainer? (VM wanderlust and others which however
    Uwe>        not part of  Emacs)

Any code in emacs that wants to connect to google services using
IMAP/SMTP (and maybe POP, if they still support that) would be
affected. That includes things like smtpmail that mailers not bundled
with Emacs can use.

Robert

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:

   >>>>>> On Mon, 10 Aug 2020 08:43:19 +0200, Uwe Brauer <oub@mat.ucm.es> said:
   Uwe> Yes, but also two comments:

   Uwe> 1. Do you have a link with an announcement of the gmail developers?

   > I posted it earlier:

   > <https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html>

   Uwe> 2. I presume such an advice would be useful for rmail, for which you
   Uwe> are still the maintainer? (VM wanderlust and others which however
   Uwe> not part of  Emacs)

   > Any code in emacs that wants to connect to google services using
   > IMAP/SMTP (and maybe POP, if they still support that) would be
   > affected. That includes things like smtpmail that mailers not bundled
   > with Emacs can use.

Ok I sent an email to dvratil@kde.org and to the kde dev mailing list,
my mail was forwarded to the relevant list, but so far no answer.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[T.V Raman]

soyeomul@doraji.xyz (황병희) writes:


That will let you send email, not read email using gnus > Uwe Brauer <oub@mat.ucm.es> writes:
>
>>> Uwe Brauer <oub@mat.ucm.es> writes:
>>
>>> LSA(less secure apps) enabling is not good. Though you would like to
>>> login into Gmail with Emacs/ssmtp/nullmailer/msmtp. The [app password --
>>> 16 digit code] is the best choice for now. In my case i did put it(app
>>> password) into /etc/ssmtp/ssmtp-gmail.conf ;;;
>>
>> Thanks for this information! But  can you elaborate it a bit? how to do
>> connect to your gmail account with gnus in this setting?
>
> Just i did replace <user-password> with <app-password> in
> /etc/ssmtp/ssmtp-gmail.conf and i did not touch ~/.gnus ;;;
>
> Sincerely, Gnus fan Byung-Hee

-- 

Re: Making GNUS continue to work with Gmail

[황병희]

"T.V Raman" <raman@google.com> writes:

> That will let you send email, not read email using gnus

Thanks for kind feedback Raman^^^ 

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Ok I sent an email to dvratil@kde.org and to the kde dev mailing list,
  > my mail was forwarded to the relevant list, but so far no answer.

Someone responded today, to you and me, so I forwarded it to Lars.
Thanks.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:

    T> soyeomul@doraji.xyz (황병희) writes:
    T> That will let you send email, not read email using gnus

You can use the same "password" in .authinfo.gpg and have it be used
for IMAP.

Robert

Re: Making GNUS continue to work with Gmail

[황병희]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:
>
>     T> soyeomul@doraji.xyz (황병희) writes:
>     T> That will let you send email, not read email using gnus
>
> You can use the same "password" in .authinfo.gpg and have it be used
> for IMAP.

Thanks Robert^^^ I am so happy with Gnus!!!

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Colin Baxter]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

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

    > Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Thu, 06 Aug 2020 10:08:11 -0700, Cesar Crusius
    >> <cesar.crusius@gmail.com> said:
    Cesar> My auth-source-xoauth2 package "avoids" that by having every
    Cesar> user do the API key dance with Google, and as a result is
    Cesar> rather hard to setup.
    >> 
    >> The nnredit package automates this by using a python script to
    >> get you to do the appropriate magic on reddit.com (from memory it
    >> fires up a browser and you just log in once). Perhaps that could
    >> be adapted to auth-source-xoauth2? (no, Iʼm not volunteering)

    > I believe reddit's app registration mechanism is simple enough
    > that you can semi-automate it. In Google's case (as you can see
    > from the the auth-source-xoauth2 package) the whole thing is quite
    > involved indeed.

Would https://luxing.im/mutt-integration-with-gmail-using-oauth/ be of
any help? This is what I have used for mutt. Forgive me if this link is
already known.

Best wishes,

Colin Baxter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Making GNUS continue to work with Gmail

[Colin Baxter]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

>>>>> Colin Baxter <m43cap@yandex.com> writes:

    > Would https://luxing.im/mutt-integration-with-gmail-using-oauth/
    > be of any help? This is what I have used for mutt. Forgive me if
    > this link is already known.

Sorry, forget this. Google's toc's don't seem compatible with "Free
Software".

Best wishes,

--
Colin Baxter
URL: http://www.Colin-Baxter.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

>>> "CB" == Colin Baxter <m43cap@yandex.com> writes:

   >>>>>> Colin Baxter <m43cap@yandex.com> writes:
   >> Would https://luxing.im/mutt-integration-with-gmail-using-oauth/
   >> be of any help? This is what I have used for mutt. Forgive me if
   >> this link is already known.

   > Sorry, forget this. Google's toc's don't seem compatible with "Free
   > Software".

What do you mean, the python script is not GPL compatible?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

>>> "CB" == Colin Baxter <m43cap@yandex.com> writes:

   >>>>>> Colin Baxter <m43cap@yandex.com> writes:
   >> Would https://luxing.im/mutt-integration-with-gmail-using-oauth/
   >> be of any help? This is what I have used for mutt. Forgive me if
   >> this link is already known.

   > Sorry, forget this. Google's toc's don't seem compatible with "Free
   > Software".


I am more confused, this software seems under Apache License version 2,
and that seems compatible with GPL 3 according to 

https://www.apache.org/licenses/GPL-compatibility.html#:~:text=The%20Free%20Software%20Foundation%20considers,version%203%20of%20the%20GPL.&text=The%20licenses%20are%20incompatible%20in,authors'%20interpretation%20of%20copyright%20law.

Most likely I miss something, but what?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:

   >>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:
   T> soyeomul@doraji.xyz (황병희) writes:
   T> That will let you send email, not read email using gnus

   > You can use the same "password" in .authinfo.gpg and have it be used
   > for IMAP.

I am confused, now, the strategy (황병희) describes could work for
gnus, even after February 15th, 2021?

Then where is the problem?

What do I miss here?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Colin Baxter]

>>>>> Uwe Brauer <oub@mat.ucm.es> writes:

    > --=-=-= Content-Type: text/plain Content-Transfer-Encoding:
    > quoted-printable

    >>>> "CB" =3D=3D Colin Baxter <m43cap@yandex.com> writes:

    >>>>>>> Colin Baxter <m43cap@yandex.com> writes:
    >>> Would https://luxing.im/mutt-integration-with-gmail-using-oauth/
    >>> be of any help? This is what I have used for mutt. Forgive me if
    >>> this link is already known.

    >> Sorry, forget this. Google's toc's don't seem compatible with
    >> "Free Software".


    > I am more confused, this software seems under Apache License
    > version 2, and that seems compatible with GPL 3 according to=20

    > https://www.apache.org/licenses/GPL-compatibility.html#:~:text=3DThe%20Free=
    > %20Software%20Foundation%20considers,version%203%20of%20the%20GPL.&text=3DT=
    > he%20licenses%20are%20incompatible%20in,authors'%20interpretation%20of%20co=
    > pyright%20law.

    > Most likely I miss something, but what?

It's not the py script but the TOCs of signing up to use google's
oauth. Visit the google link given in the blog.

Best wishes,





Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------

Re: Making GNUS continue to work with Gmail

[Mingde (Matthew) Zeng]

On a side note, M$ Outlook is also dropping support for IMAP/SMTP. See https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/

Whether one likes it or not, Outlook is the default email solution for many companies and unviersities, including mine. Therefore we need to think of a solution that preferably works for more than just Gmail.

(What's more obsurd is that the IT team at my university already decided to terminate IMAP support themselves earlier this year "to avoid future troubles" which effectively broke my MUA completely.)

Thanks,
Matthew


Richard Stallman <rms@gnu.org> writes:

> To keep GNUS working with Gmail, we need to talk with the developers
> of Kmail about how they did it.  But I have no contact with them.
>
> Would someone please volunteer to find them and ask them to talk with
> us and give us advice?
>
> If you succeed in finding someone ready, willing and able to advise
> us, please put per in touch with me and Lars Ingebrigtsen
> <larsi@gnus.org> by email.


--
Mingde (Matthew) Zeng

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Tue, 11 Aug 2020 17:25:27 +0200, Uwe Brauer <oub@mat.ucm.es> said:

    >>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:
    T> soyeomul@doraji.xyz (황병희) writes:
    T> That will let you send email, not read email using gnus

    >> You can use the same "password" in .authinfo.gpg and have it be used
    >> for IMAP.

    Uwe> I am confused, now, the strategy (황병희) describes could work for
    Uwe> gnus, even after February 15th, 2021?

    Uwe> Then where is the problem?

    Uwe> What do I miss here?

The problem is that today you can turn on 'app specific passwords',
and generate one for Gnus to use, and thatʼs the end of it. Tomorrow
you need to generate an Oauth2 token by registering an 'app' with
Google, jumping through some more hoops, and generating a 'token' that
you then use with Gnus. Google can probably revoke that token whenever
they want, and then you need to jump through the hoops again.

The end result is the same: a string that Gnus uses for
authentication. The proces to get it will require logging into Google
with a browser [1], and cutting and pasting a bunch of identifiers around,
which is much more involved and easier to mess up.

The alternative is to register an 'Emacs' app, do the hoop jumping,
and stick the various secret tokens in the Emacs sources, but as I
understand it thatʼs expressly forbidden by Google's terms-of-use
(correct me if Iʼm wrong, I haven't read them).

Iʼm starting to agree with Stefan here: maybe itʼs time to start using
a different email provider.

Robert

Footnotes:
[1]  This is in itself problematic for some people, since this
     requires running non-Free javascript code.

Re: Making GNUS continue to work with Gmail

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Tue, Aug 11, 2020 at 5:11 PM Robert Pluim <rpluim@gmail.com> wrote:

> The alternative is to register an 'Emacs' app, do the hoop jumping,
> and stick the various secret tokens in the Emacs sources, but as I
> understand it thatʼs expressly forbidden by Google's terms-of-use
> (correct me if Iʼm wrong, I haven't read them).
>

Thanks for the clear explanation. I suppose this will affect mbsync/isync
as well. Is it very hard to design a program that periodically does
all that "hoop jumping" for me and and writes to ~/.authinfo or to
pass(1)'s password store?

Iʼm starting to agree with Stefan here: maybe itʼs time to start using
> a different email provider.
>

Maybe. But, sorry for the naive question, do you plan to throw
the gmail address away?

João,
who had just gotten mbsync/gnus working decently some months ago

[-- Attachment #2: Type: text/html, Size: 1448 bytes --]

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Tue, 11 Aug 2020 19:05:51 +0100, João Távora <joaotavora@gmail.com> said:

    João> On Tue, Aug 11, 2020 at 5:11 PM Robert Pluim <rpluim@gmail.com> wrote:
    >> The alternative is to register an 'Emacs' app, do the hoop jumping,
    >> and stick the various secret tokens in the Emacs sources, but as I
    >> understand it thatʼs expressly forbidden by Google's terms-of-use
    >> (correct me if Iʼm wrong, I haven't read them).
    >> 

    João> Thanks for the clear explanation. I suppose this will affect mbsync/isync
    João> as well. Is it very hard to design a program that periodically does
    João> all that "hoop jumping" for me and and writes to ~/.authinfo or to
    João> pass(1)'s password store?

If Iʼm not mistaken, the python script used by mutt that was mentioned
earlier does quite a bit of it. I donʼt know if it could be rewritten
in elisp.

    João> Iʼm starting to agree with Stefan here: maybe itʼs time to start using
    >> a different email provider.
    >> 

    João> Maybe. But, sorry for the naive question, do you plan to throw
    João> the gmail address away?

Iʼve fallen into the Google trap the same as many have: too much of my
life, online and off, depends on that address, so Iʼd have to set up a
forwarder. [1]

    João> João,
    João> who had just gotten mbsync/gnus working decently some months ago

If this is 'no-cost' gmail, I think that might continue working for a
while (at least until someone at Google decides itʼs 'legacy' and
forces everyone to OAuth2, much like Microsoft are doing).

Robert "feeling like a very grumpy old man at the moment"

Footnotes:
[1]  If Iʼm feeling really brave Iʼll follow Lars' "how to set up a
     modern SMTP server" guide.

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Yesterday I forward to Lars Ingebrigtsen a message from a Kmail developer
explaining how they handled this problem.  I suggest we and the parallel
threads which are based on less knowledge, and wait till he says whether
it is feasible to follow that path.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Whether one likes it or not, Outlook is the default email solution
  > for many companies and unviersities, including mine. Therefore we
  > need to think of a solution that preferably works for more than
  > just Gmail.

We can't even start to think about that in the abstract.
We need a concrete question.

What public interfaces does Outlook support?

  > (What's more obsurd is that the IT team at my university already
  > decided to terminate IMAP support themselves earlier this year "to
  > avoid future troubles" which effectively broke my MUA completely.)

What public interfacess do they support?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Sorry, forget this. Google's toc's don't seem compatible with "Free
  > Software".

That is a very vague statement.  Could you show us (copy the text of)
the specific terms in which you see a problem?

Also, Google has many different sets of terms and conditions.
What is the URL of the ones you are talking about?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Making GNUS continue to work with Gmail

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]

I share your sentiment about using different mail provider. Personally I have gmail and outlook (live) accounts, but I would rather skip both if I could. Alternative to me is what my ISP offers, but that changes when I switch ISP so it is not a "stable" as gmail/outlook. I think that my current ISP does not even offer email service, but I am not sure.

I would gladly pay for a "free" email service that guarantees my privacy, so somebody should hint FSF/GNU people for possible business opportunity here :-).

Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: Robert Pluim <rpluim@gmail.com>
Datum: 2020-08-11 18:11 (GMT+01:00)
Till: emacs-devel@gnu.org
Ämne: Re: Making GNUS continue to work with Gmail

>>>>> On Tue, 11 Aug 2020 17:25:27 +0200, Uwe Brauer <oub@mat.ucm.es> said:

    >>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:
    T> soyeomul@doraji.xyz (황병희) writes:
    T> That will let you send email, not read email using gnus

    >> You can use the same "password" in .authinfo.gpg and have it be used
    >> for IMAP.

    Uwe> I am confused, now, the strategy (황병희) describes could work for
    Uwe> gnus, even after February 15th, 2021?

    Uwe> Then where is the problem?

    Uwe> What do I miss here?

The problem is that today you can turn on 'app specific passwords',
and generate one for Gnus to use, and thatʼs the end of it. Tomorrow
you need to generate an Oauth2 token by registering an 'app' with
Google, jumping through some more hoops, and generating a 'token' that
you then use with Gnus. Google can probably revoke that token whenever
they want, and then you need to jump through the hoops again.

The end result is the same: a string that Gnus uses for
authentication. The proces to get it will require logging into Google
with a browser [1], and cutting and pasting a bunch of identifiers around,
which is much more involved and easier to mess up.

The alternative is to register an 'Emacs' app, do the hoop jumping,
and stick the various secret tokens in the Emacs sources, but as I
understand it thatʼs expressly forbidden by Google's terms-of-use
(correct me if Iʼm wrong, I haven't read them).

Iʼm starting to agree with Stefan here: maybe itʼs time to start using
a different email provider.

Robert

Footnotes:
[1]  This is in itself problematic for some people, since this
     requires running non-Free javascript code.



[-- Attachment #2: Type: text/html, Size: 3875 bytes --]

Re: Making GNUS continue to work with Gmail

[황병희]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Yesterday I forward to Lars Ingebrigtsen a message from a Kmail developer
> explaining how they handled this problem.  I suggest we and the parallel
> threads which are based on less knowledge, and wait till he says whether
> it is feasible to follow that path.

Yes i'll wait for Lars. I like him. Also he Lars is honorable man.

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Colin Baxter]

>>>>> Richard Stallman <rms@gnu.org> writes:

    > [[[ To any NSA and FBI agents reading my email: please consider
    > ]]] [[[ whether defending the US Constitution against all enemies,
    > ]]] [[[ foreign or domestic, requires you to follow Snowden's
    > example. ]]]

    >> Sorry, forget this. Google's toc's don't seem compatible with
    >> "Free Software".

    > That is a very vague statement.  Could you show us (copy the text
    > of) the specific terms in which you see a problem?

    > Also, Google has many different sets of terms and conditions.
    > What is the URL of the ones you are talking about?

I made the comment in relation to a blog post mentioned in the thread;
specifically to
https://luxing.im/mutt-integration-with-gmail-using-oauth/ and the TOCs
relating to https://console.cloud.google.com/apis/credentials. I am not
a Lawyer and only cursorily read Google's extensive Terms from the latter
URL - hence my use of the qualifier "don't seem compatible".

Best wishes,



Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Wed, Aug 12, 2020 at 03:41:25AM +0000, arthur miller wrote:
> I share your sentiment about using different mail provider. Personally I have gmail and outlook (live) accounts, but I would rather skip both if I could. Alternative to me is what my ISP offers, but that changes when I switch ISP so it is not a "stable" as gmail/outlook. I think that my current ISP does not even offer email service, but I am not sure.
> 
> I would gladly pay for a "free" email service that guarantees my privacy, so somebody should hint FSF/GNU people for possible business opportunity here :-).

There are. Depending on your tastes, riseup.net might qualify
(those are even voluntary contribution).

Over here in Germany, posteo.de and mailbox.org come to mind.

Search locally: most of those offers aren't "big names" for a
reason.

> Skickat från min Samsung Galaxy-smartphone.

Hey, your phone is posting ads here! Tell him to behave ;-)

Cheers
 - tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Tue, Aug 11, 2020 at 10:28:40PM -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Whether one likes it or not, Outlook is the default email solution
>   > for many companies and unviersities, including mine. Therefore we
>   > need to think of a solution that preferably works for more than
>   > just Gmail.
> 
> We can't even start to think about that in the abstract.
> We need a concrete question.
> 
> What public interfaces does Outlook support?

Outlook is the client (kind-of MUA). The server is called Exchange [1],
which, if the admins are friendly, can support IMAP (well, some sort
of Microsoft bastardized IMAP, but which works reasonably).

But I've heard that Microsoft is softly trying to push their clients
off IMAP (which makes sense, since, as they are losing grip with their
(non-)operating system offers, they are trying to re-gain it with their
all-in-one enterprise lock-in offers aka Office 356.

Cheers

[1] I always understood that name as an incitation, as in "Exchange
   this server, please"

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:

   >>>>>> On Tue, 11 Aug 2020 17:25:27 +0200, Uwe Brauer <oub@mat.ucm.es> said:
   >>>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:
   >>>>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> said:
   T> soyeomul@doraji.xyz (황병희) writes:
   T> That will let you send email, not read email using gnus

   >>> You can use the same "password" in .authinfo.gpg and have it be used
   >>> for IMAP.

   Uwe> I am confused, now, the strategy (황병희) describes could work for
   Uwe> gnus, even after February 15th, 2021?

   Uwe> Then where is the problem?

   Uwe> What do I miss here?

   > The problem is that today you can turn on 'app specific passwords',
   > and generate one for Gnus to use, and thatʼs the end of it. Tomorrow
   > you need to generate an Oauth2 token by registering an 'app' with
   > Google, jumping through some more hoops, and generating a 'token' that
   > you then use with Gnus. Google can probably revoke that token whenever
   > they want, and then you need to jump through the hoops again.

   > The end result is the same: a string that Gnus uses for
   > authentication. The proces to get it will require logging into Google
   > with a browser [1], and cutting and pasting a bunch of identifiers around,
   > which is much more involved and easier to mess up.

   > The alternative is to register an 'Emacs' app, do the hoop jumping,
   > and stick the various secret tokens in the Emacs sources, but as I
   > understand it thatʼs expressly forbidden by Google's terms-of-use
   > (correct me if Iʼm wrong, I haven't read them).

Ok, now I understand the issue this is really bad and a clear example of
locked it.

   > Iʼm starting to agree with Stefan here: maybe itʼs time to start using
   > a different email provider.

Right now this is not possible for me, or at least I am not willing to
spend private money to access my work email.

In the academic world, at least 50 are using MUA and not the web
interface. This will also put an end to encrypted email, at least for smime[1]
I hope would can get around using the ideas expressed in the python
script approach.


I wonder if it makes some sense to try to talk to the google folks.


Uwe 

Footnotes:
[1]  there are some solution, but it was never clear to me where the
     certificates are stored.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Wed, Aug 12, 2020 at 08:54:33AM +0200, Uwe Brauer wrote:

[...]

> I wonder if it makes some sense to try to talk to the google folks.

You think all of this is unintentional on their [1] part?

Cheers

[1] "their" in the sense of "corporate strategy". Now if you'd
   get the folks working at Google interested on that topic, that
   might be a Big Win (TM).

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Tuesday, 11 Aug 2020 at 18:11, Robert Pluim wrote:
> Iʼm starting to agree with Stefan here: maybe itʼs time to start using
> a different email provider.

I started this process a couple of years ago now (due to Brexit and the
negative impact on data protection), moving to a paid for email account
so no data selling.  It's scary how long it takes to move everything to
another email provider; however, I'm almost there.

The long term solution is your own domain etc.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Wed, Aug 12, 2020 at 03:41:25AM +0000, arthur miller wrote:
>> I share your sentiment about using different mail provider. Personally I have
>> gmail and outlook (live) accounts, but I would rather skip both if I could.
>> Alternative to me is what my ISP offers, but that changes when I switch ISP so
>> it is not a "stable" as gmail/outlook. I think that my current ISP does not
>> even offer email service, but I am not sure.
>> 
>> I would gladly pay for a "free" email service that guarantees my privacy, so somebody should hint FSF/GNU people for possible business opportunity here :-).
>
> There are. Depending on your tastes, riseup.net might qualify
> (those are even voluntary contribution).

That was an interesting offer! On paper that sounds awesome, question is
how long-lasting they will be. Second - who the heck they are? Being
born in a communist/socialist country I am a bit suspect of their
left-rhetorics and anonymous "collective". I do share their ideas,
sentiments and values, but they are completely anoynomous and thus
non-transparent, so how can I trust them?

Actually I wrote paragraph about my opinion on how essential is for
communication to be free for a democracy to thrive, but then I erased it
before I posted it; thought it was unnecessary with politics and my
personal beliefs on emacs-dev list.

> Over here in Germany, posteo.de and mailbox.org come to mind.
>
> Search locally: most of those offers aren't "big names" for a
> reason.

You might be correct. I haven't really being looking around myself. But
I would still prefer to help monetary some organisation I trust (like
FSF/GNU).

>> Skickat från min Samsung Galaxy-smartphone.
>
> Hey, your phone is posting ads here! Tell him to behave ;-)
>
> Cheers
>  - tomás
Interesting how information is interpretted. I would rather say this was
a pure statement from my phone rather then an ad: it didn't say - go by
me! :-). (I was at the go, didn't have access to Emacs :-)).

Re: Making GNUS continue to work with Gmail

[Arthur Miller]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Tuesday, 11 Aug 2020 at 18:11, Robert Pluim wrote:
>> Iʼm starting to agree with Stefan here: maybe itʼs time to start using
>> a different email provider.

> The long term solution is your own domain etc.
Domain itself is maybe not enought, you probably think of running own
mailserver/website etc?

Running own server requires resources and knowledge most people don't
have, a 24/7 machine that has to be secured in a proper way.

Using a webhotel will still put user data on some corporate server that
will probably oblige to whatever "legal" request local goverment might
impose on them. Imagine having  your domain in a place like Belarus or
China. Even some of "free and democratic" countries are nowdays imposing
laws and "security" measurea that can hardly be seen as free and democratic.

For example here in Sweden they have recently passed a law that allows
police to hack into any personal computer or phone without legal request
to and authorisation by a court, on a mere suspicion of a crime.
Earlier they needed to acquire a legal permission from a public
prosecutor by presenting their suspicions and evidence for those. We
still have some way to go untill we reach Belarus level, but as it seems
by public and media's lack of concern, nothing is impossible even here.

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

>>>   <tomas@tuxteam.de> writes:

> On Wed, Aug 12, 2020 at 08:54:33AM +0200, Uwe Brauer wrote:
> [...]

>> I wonder if it makes some sense to try to talk to the google folks.

> You think all of this is unintentional on their [1] part?

Well no, but they might have trouble convincing in the future
universities or other research facilities to change to their GSuites.

> Cheers

> [1] "their" in the sense of "corporate strategy". Now if you'd
>    get the folks working at Google interested on that topic, that
>    might be a Big Win (TM).

I wait for the verdict, of the master, Lars, to see what he thinks.
That is whether either the python script approach a la mutt or the
approach of Daniel Vrátil is doable for GNUS and whether RMS
approves it, of course.

When my university years ago switched to gmail, I thought what a
relieve! No space problem, no server shutting down unexpectedly. Using
smime encryption also made it more difficult for them to scan my email,
but this move really destroys all of the sudden the pros I found with
gmail. I wished now, they wouldn't have done it.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Wednesday, 12 Aug 2020 at 14:40, Arthur Miller wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>> The long term solution is your own domain etc.
> Domain itself is maybe not enought, you probably think of running own
> mailserver/website etc?
>
> Running own server requires resources and knowledge most people don't
> have, a 24/7 machine that has to be secured in a proper way.

Sorry, I should have been a little more verbose.  Yes, you are perfectly
right: the domain itself is not enough.  It needs to be hosted somewhere
and hosting is a lot of work.  

I wouldn't intend to host myself; there are plenty of hosting servers
out there.  The point I was trying to make is that you can then move
your email from one host to another without having to change email
address.  It's this latter aspect that makes us so vulnerable to moves
by Google/MS/et al. to restrict access.

I have no idea what I will do about my work email (which I use for
newsgroups) as that is hosted by MS and they also are getting rid of
direct IMAP/POP access later this year, I believe.  I cannot imagine
handling the volume of email I get without the adaptive scoring,
intelligent splitting, and full keyboard control that gnus
provides.  Hey hum.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Stefan Monnier]

> That was an interesting offer! On paper that sounds awesome, question is
> how long-lasting they will be. Second - who the heck they are? Being
> born in a communist/socialist country I am a bit suspect of their
> left-rhetorics and anonymous "collective". I do share their ideas,
> sentiments and values, but they are completely anoynomous and thus
> non-transparent, so how can I trust them?

Indeed, you can't be very sure of anything in this respect, except that
you know for sure that Google will do its best to monetize your data.

> Actually I wrote paragraph about my opinion on how essential is for
> communication to be free for a democracy to thrive,

I think the real threat is centralization of power.  While it may turn
out that those small providers are in reality all secretly under the
control of Google, it's sufficiently unlikely IMO.

> You might be correct. I haven't really being looking around myself.
> But I would still prefer to help monetary some organisation I trust
> (like FSF/GNU).

;-)

>>> Skickat från min Samsung Galaxy-smartphone.
>> Hey, your phone is posting ads here! Tell him to behave ;-)
>> Cheers
>>  - tomás
> Interesting how information is interpretted. I would rather say this was
> a pure statement from my phone rather then an ad: it didn't say - go by
> me! :-). (I was at the go, didn't have access to Emacs :-)).

The presence of the brand name there is very clearly present for
advertisement reasons.  Most of advertisement focuses on
name-recognition, rather than on directly getting you to buy something.


        Stefan

Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

On Wed, Aug 12, 2020 at 02:11:01PM +0200, Arthur Miller wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Wed, Aug 12, 2020 at 03:41:25AM +0000, arthur miller wrote:
> >> I share your sentiment about using different mail provider. Personally I have
> >> gmail and outlook (live) accounts, but I would rather skip both if I could.
> >> Alternative to me is what my ISP offers, but that changes when I switch ISP so
> >> it is not a "stable" as gmail/outlook. I think that my current ISP does not
> >> even offer email service, but I am not sure.
> >> 
> >> I would gladly pay for a "free" email service that guarantees my privacy, so somebody should hint FSF/GNU people for possible business opportunity here :-).
> >
> > There are. Depending on your tastes, riseup.net might qualify
> > (those are even voluntary contribution).
> 
> That was an interesting offer! On paper that sounds awesome, question is
> how long-lasting they will be.

You never know. But if past is any indication... they are around since
about 2000, so that's twenty years.

>                           Second - who the heck they are? Being
> born in a communist/socialist country I am a bit suspect of their
> left-rhetorics and anonymous "collective". I do share their ideas,
> sentiments and values, but they are completely anoynomous and thus
> non-transparent, so how can I trust them?

They do have a political slant, true. But they are up-front about
it, so each one can decide.

[...]

> > Search locally: most of those offers aren't "big names" for a
> > reason.
> 
> You might be correct. I haven't really being looking around myself. But
> I would still prefer to help monetary some organisation I trust (like
> FSF/GNU).

They are focussed on free software. I don't think they are in the mail
provider "business". If you want to host a free project... Savannah might
fit the bill.

> >> Skickat från min Samsung Galaxy-smartphone.
> >
> > Hey, your phone is posting ads here! Tell him to behave ;-)

> Interesting how information is interpretted. I would rather say this was
> a pure statement from my phone rather then an ad: it didn't say - go by
> me! :-). (I was at the go, didn't have access to Emacs :-)).

't was a bit tongue-in-cheek, although from time to time it becomes a
tad tiresome to read all those "this mail was hand-made on that AWESOME
y-Phone!!!

Nevermind :) Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gmail

[Eric Abrahamsen]

Arthur Miller <arthur.miller@live.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Tuesday, 11 Aug 2020 at 18:11, Robert Pluim wrote:
>>> Iʼm starting to agree with Stefan here: maybe itʼs time to start using
>>> a different email provider.
>
>> The long term solution is your own domain etc.
> Domain itself is maybe not enought, you probably think of running own
> mailserver/website etc?

For Gmail users, one potential "intermediate step" could look like:

- Get your own domain
- Start a Google Apps account as part of your google account, using your
  new custom domain.
- Use this new domain as a new Gmail account
- Start the long process of "external migration": getting people to stop
  using your @gmail.com account, and start using your @custom.me
  account. Set up automatic forwarding from gmail to custom, etc.
- Set up a local sync of your @custom.me mail
- When you're ready, switch your @custom.me MX records to your new mail
  provider, and sync mail up to it.

This way you can take as long as you like to do the social work of
migrating to a new email address. Another bonus is that, since Google
once saw @custom.me as a gmail-backed address, it will have whitelisted
it for deliverability. My understanding is that that whitelist doesn't
go away after you switch your MX records, solving (one part of) your
potential deliverability problem.

I have no insight into how Google works, this is just what I've heard. I
did this with two different email addresses (luckily I never used
@gmail.com, they were custom from the start) and I have had nearly no
gmail-related deliverability problems since switching to self-hosting my
email.

YMMV, in a big way.

Eric

Re: Making GNUS continue to work with Gmail

[황병희]

> what a relieve! No space problem, no server shutting down
> unexpectedly.

Same here. That is very very very IMPORTANT!!!

Sincerely, Gnus-Gmail fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: Making GNUS continue to work with Gmail

[Stefan Monnier]

> When my university years ago switched to gmail, I thought what a
> relieve!  No space problem, no server shutting down unexpectedly.

Note that the space problem fixed itself even without moving over to
Gmail, simply because of increasing disk capacity (and better IMAP
servers that weren't swamped by too-large mbox files).


        Stefan

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> When my university years ago switched to gmail, I thought what a
>> relieve!  No space problem, no server shutting down unexpectedly.

> Note that the space problem fixed itself even without moving over to
> Gmail, simply because of increasing disk capacity (and better IMAP
> servers that weren't swamped by too-large mbox files).

Normally yes, but not if your workplace has an insufficient amount of
competent people, and also if your university president agrees to
install an Exchange server, then has no money to pay the maintenance
fees and has no money for a hardware upgrade, then, indeed, a Gmail
offer is very tempting.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden]

On 11/08/2020 17:11, Robert Pluim wrote:

> 
> The alternative is to register an 'Emacs' app, do the hoop jumping,
> and stick the various secret tokens in the Emacs sources, but as I
> understand it thatʼs expressly forbidden by Google's terms-of-use
> (correct me if Iʼm wrong, I haven't read them).


Just looked vaguely into this as a thunderbird and emacs user / 
emacs-devel ghost. I was left seriously wondering how+why thunderbird 
was still working with a gmail account (just a secondary email in my 
case, fortunately), having seen this thread. Anyway, decided to write it 
up and share it in case it's useful.  Sorry for wall of text, tried to 
structure it somewhat:

*1. Non-secret "client secrets".
*2. What Thunderbird does data point, and not just a google problem
*3. End-User supply of and/or override of client id and secret
*4. Technical implementation note, separation of implementation vs 
official id concerns

*1. Non-secret "client secrets":

That  assumption that people including google really think these 
particular "secrets" are real secrets that are required to be be kept 
secret may be false?   Google do appear to recognise and accept such 
desktop app hardcoded static client ids and "secrets" they issue aren't 
actually secret in this case, just some bits anyone can easily snaffle e.g.

https://developers.google.com/identity/protocols/oauth2/native-app

"""
Note: incremental authorization with installed apps is not supported due 
to the fact that the client cannot keep the client_secret confidential.
"""

Regarding "not supported" there - in context that doesn't mean authc and 
non-incremental authz don't work, my point quoting the above was not 
that aspect of it, just that you can see they appear to be well aware 
the so-called client secret is not a secret in any meaningful sense in 
the overall native-app-installed-on-client-desktops flow they are 
talking about.

And let's see the rfc8252 google cite, note it says (quite amusingly):

https://tools.ietf.org/html/rfc8252#section-8.5

""""
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret.
"""

And IIUC a near-mandatory protocol extension (pkce rfc7636, 
https://oauth.net/2/pkce/ ) means core security properties are not or no 
longer strongly linked to these particular "secrets" being secret.

=> I think they're not real secrets?  Not to say a lot of attention to 
the legal side wouldn't still be required if an official  client id and 
secret were sought.

Google further apparently doesn't support "dynamic client registration" 
(I think unlike a lot of in-house corporate auth servers using oauth2 on 
intranets as a "modern" kerberos replacement?), so such valid static app 
client ids and secrets can only be obtained via their full web interface 
for issuing and approval workflow, which would certainly still involve 
agreeing to lots of incomprehensible legalese things.

https://stackoverflow.com/questions/36260097/is-openid-connect-dynamic-client-registration-possible-with-google


*2. What Thunderbird does data point, and not just a google problem:

Now, definitely no idea of legalities it happens under either, nor 
advocating emacs should necessarily take the same approach, but as a 
data point, it looks to me like Mozilla Thunderbird (MPL2.0 licensed) at 
time of writing does appear to be simply openly embedding a bunch of 
static oauth2 app client ids and client (non-)secrets for

Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft

https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51


*** If nothing else, seems clear it is already becoming not just a 
google problem.

Presumably someone from Mozilla applied for and got those ids and 
secrets from each provider.

And of course, even if it's legally okay for someone acting for GNU to 
similarly get some static client ids and (non-)secrets issued from 
google (and the others) to similarly embed openly in the GNU Emacs 
official sources, subject to their approval whims whatever they may be - 
and seems like a "pray I do not alter the deal further" scenario, sigh, 
can certainly imagine them just turning it off later. Or turning on 
billing: given google, I'd also be vaguely suspicious about them not 
using it super-maliciously, but being able to use it as a key (in a db 
sense) for trying to charge an app developer instead of an end user,



*3. End-User supply of and/or override of client id and secret:

There is strong precedent there in that the chromium codebase itself 
also supports  env vars setting of arbitrary user-specified runtime 
override api access client ids and secrets when it doesn't have its own 
hardcoded embedded ones compiled in, or if a dev just wants to use 
different ones:

https://www.chromium.org/developers/how-tos/api-keys

I believe e.g. debian doesn't or didn't build their chromium with them, 
but still allows users to supply their own if they want by that mechanism.



*4. Technical implementation note, separation of implementation vs 
official id concerns:

Also to note Julien Danjou appears to have already written an emacs 
oauth2 package:

https://elpa.gnu.org/packages/oauth2.html

(defun oauth2-auth-and-store (auth-url token-url scope client-id 
client-secret &optional redirect-uri state)

(and with the likes of elnode, I guess the open a transient localhost 
port redirect uri flow is viable to streamline token acquisition)

Presumably any emacs implementation for imap access use could easily 
allow for end-user customizable override of either a prepopulated table, 
or an empty table of the required provider, static client id, client 
secret, mappings.

=> the technical side looks doable (especially since a lot of it looks 
already done by Julien) and is not actually google specific (and may be 
useful for both other public providers and private in-house ones in 
companies etc.), it does look to me like the decision of whether to 
implement the facility at all (that may still be playing into their 
hands in a sense of course) could be made independently of whether to 
actually apply for and embed an official static client ids and secrets 
for the various public providers who apparently want one, including, but 
not limited to, google in particular?

Re: Making GNUS continue to work with Gmail

[David Engster]

> Google do appear to recognise and accept such
> desktop app hardcoded static client ids and "secrets" they issue
> aren't actually secret in this case, just some bits anyone can easily
> snaffle e.g.
>
> https://developers.google.com/identity/protocols/oauth2/native-app
>
> """
> Note: incremental authorization with installed apps is not supported
> due to the fact that the client cannot keep the client_secret
> confidential.
> """

Yes, they aknowledge this fact. And yet they explicitly forbid embedding
these secrets into (F)OSS applications. See

  https://developers.google.com/terms

Section 4b, first paragraph.

So what Thunderbird and many other applications do is against these
terms of service. Google can at any point revoke the client id and ban
the corresponding developer account.

Maybe the FSF should simply register a client id and secret and make it
public for any GPL application to use.

-David

Re: Making GNUS continue to work with Gmail

[Stefan Monnier]

> Yes, they aknowledge this fact. And yet they explicitly forbid embedding
> these secrets into (F)OSS applications. See
>
>   https://developers.google.com/terms
>
> Section 4b, first paragraph.

It says:

    Developer credentials may not be embedded in open source projects.

Lucky for us, our projects aren't open source but Free Software ;-)


        Stefan

Re: Making GNUS continue to work with Gmail

[Lars Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> Yes, they aknowledge this fact. And yet they explicitly forbid embedding
> these secrets into (F)OSS applications. See
>
>   https://developers.google.com/terms
>
> Section 4b, first paragraph.

For those that don't like following links:

b. Confidential Matters

1 Developer credentials (such as passwords, keys, and client IDs) are intended to
 be used by you and identify your API Client. You will keep your credentials
 confidential and make reasonable efforts to prevent and discourage other API
 Clients from using your credentials. Developer credentials may not be embedded
 in open source projects.

The FSF may, of course, just say "well, we don't care about whatever is
in that stupid terms of condition -- we're for free software, and we
think these terms are immoral, and so we'll just ignore them (while
using the API)".  And that'd be fine.

But somebody at the FSF would need to register a developer account with
Google, in the FSF's name, and get ready to be sued (or billed; Google
have a way of saying "well, now you're using this API so much that you
have to pay" at random) by Google.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making GNUS continue to work with Gmail

[Lars Ingebrigtsen]

David De La Harpe Golden <david@harpegolden.net> writes:

> Anyway, decided to write it up and share it in case it's useful.
> Sorry for wall of text, tried to structure it somewhat:

Thank you; it's the most cogent article I've read on this subject.  :-)
Just some short comments:

> And IIUC a near-mandatory protocol extension (pkce rfc7636,
> https://oauth.net/2/pkce/ ) means core security properties are not or
> no longer strongly linked to these particular "secrets" being secret.

Yeah, they're not secret secrets, but just a way to make a specific
entity take responsibility for a class of API usage, which enables
easier tracking (and later billing).

> *2. What Thunderbird does data point, and not just a google problem:
[...]
> Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft
>
> https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51

I guess it would be rude for Emacs to just use those credentials.  :-)

> *3. End-User supply of and/or override of client id and secret:
[...]
> https://www.chromium.org/developers/how-tos/api-keys
>
> I believe e.g. debian doesn't or didn't build their chromium with
> them, but still allows users to supply their own if they want by that
> mechanism.
[...]
> Also to note Julien Danjou appears to have already written an emacs
> oauth2 package:
>
> https://elpa.gnu.org/packages/oauth2.html

Yeah, we could just use that and tell the users to "just" register their
own developer accounts at Google and then put the keys somewhere.  It's
a really really horrid experience to go through, though, and Google will
sic an API compliancy review at the users at random.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]


> David De La Harpe Golden <david@harpegolden.net> writes:

> Thank you; it's the most cogent article I've read on this subject.  :-)
> Just some short comments:


> Yeah, they're not secret secrets, but just a way to make a specific
> entity take responsibility for a class of API usage, which enables
> easier tracking (and later billing).

> [...]

> I guess it would be rude for Emacs to just use those credentials.  :-)

> [...]
> [...]

> Yeah, we could just use that and tell the users to "just" register their
> own developer accounts at Google and then put the keys somewhere.  It's
> a really really horrid experience to go through, though, and Google will
> sic an API compliancy review at the users at random.

What's about the approach recommended by a mutt user


https://luxing.im/mutt-integration-with-gmail-using-oauth/

Could that somehow be used for Gnus?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Lars Ingebrigtsen]

Uwe Brauer <oub@mat.ucm.es> writes:

>> Yeah, we could just use that and tell the users to "just" register their
>> own developer accounts at Google and then put the keys somewhere.  It's
>> a really really horrid experience to go through, though, and Google will
>> sic an API compliancy review at the users at random.
>
> What's about the approach recommended by a mutt user
>
> https://luxing.im/mutt-integration-with-gmail-using-oauth/
>
> Could that somehow be used for Gnus?

That's the approach you quoted me describing.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >>> Yeah, we could just use that and tell the users to "just" register their
   >>> own developer accounts at Google and then put the keys somewhere.  It's
   >>> a really really horrid experience to go through, though, and Google will
   >>> sic an API compliancy review at the users at random.
   >> 
   >> What's about the approach recommended by a mutt user
   >> 
   >> https://luxing.im/mutt-integration-with-gmail-using-oauth/
   >> 
   >> Could that somehow be used for Gnus?

   > That's the approach you quoted me describing.  :-)

I admit that I am unable to distinguish between the mutt approach and
the kmail(kontact) approach, one relies on a python script and the other?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>
>>> Yeah, we could just use that and tell the users to "just" register their
>>> own developer accounts at Google and then put the keys somewhere.  It's
>>> a really really horrid experience to go through, though, and Google will
>>> sic an API compliancy review at the users at random.
>>
>> What's about the approach recommended by a mutt user
>>
>> https://luxing.im/mutt-integration-with-gmail-using-oauth/
>>
>> Could that somehow be used for Gnus?
>
> That's the approach you quoted me describing.  :-)

... and the approach _already implemented_ by auth-source-xoauth2, which works for Gnus and anything else using auth-source in Emacs:

https://github.com/ccrusius/auth-source-xoauth2

(There is some hackery involved in `auth-source-xoauth2-enable` in order to make the protocol work for IMAP/SMTP.)

It looks like this approach keeps popping up as a "possible solution," so I'll just point out again that this is _already implemented_ in the package above, and is being used by various people to make Gnus work with Gmail and XOAuth2. The discussion here is about how to _avoid_ having to do that.

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, they aknowledge this fact. And yet they explicitly forbid embedding
  > these secrets into (F)OSS applications. See

You're reprising the discussion we had a month ago.

We already know about this.  Nonetheless, it seems that Google allows
Kmail to do so.  We are exploring what we need to do.

In the mean time, I suggest not continuing a duplicate discussion.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It looks like this approach keeps popping up as a "possible solution," so I'll just point out again that this is _already implemented_ in the package above, and is being used by various people to make Gnus work with Gmail and XOAuth2. The discussion here is about how to _avoid_ having to do that.

What IS "this approach"?  Does it get a key that GNUS can use for everyone?
Does it have each user get a key from Google?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> What IS "this approach"?  Does it get a key that GNUS can use for 
> everyone? Does it have each user get a key from Google?
>

For the sake of clarity, there are two possible approaches:

1. Each user creates its own OAuth credentials, and uses them to access 
their own Google account.  From the point of view of Google, this is as if 
each user created its own app.  This is the solution chosen by Mutt and 
others.  Its main advantage is that the process is immediate (it takes 
only a few minutes).  Its main drawback is that it is a rather complex 
process.

2. The developer creates OAuth credentials, and includes them in the 
program.  From the point of view of Google, only one app exists, with many 
users.  This is the apparently the solution chosen by Kmail, Thunderbird 
and others.  Its main advantage is that it makes the process very simple 
(almost transparent) for users: when they add a Google account to their 
mail client, a Google page is opened in a browser, they indicate their 
login and password, and that's all.  Its main drawback is that it is a 
long process, because Google has to review and approve the app.  It 
requires at least: (1) having a domain name for the app, (2) writing a 
privacy policy for the app, (3) creating a video that demonstrates the 
OAuth grant process in the app, (4) submitting the app for verification to 
Google, and waiting that it be approved.

For the sake of completeness, there is in fact a third possible approach, 
which cannot be used by regular Gmail users:

3. If your Google account is a G Suite account (either a business one or 
an education one), that is, if your email is managed by Google but your 
email address does is not an @gmail.com address, then the G Suite 
administrator can do the process (1) above once for all users of a given 
mail client.  That is, the mail client is approved once for all users of 
that domain without the need of a review by Google.

Gregory

Re: Making GNUS continue to work with Gmail

[Robert Pluim]

>>>>> On Sat, 15 Aug 2020 00:44:25 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> It looks like this approach keeps popping up as a "possible
    Richard> solution," so I'll just point out again that this is _already
    Richard> implemented_ in the package above, and is being used by various people
    Richard> to make Gnus work with Gmail and XOAuth2. The discussion here is about
    Richard> how to _avoid_ having to do that.

    Richard> What IS "this approach"?  Does it get a key that GNUS can use for everyone?
    Richard> Does it have each user get a key from Google?

The latter. Basically each user has to log in to the google developer
'console' with a web browser and register themselves, and then perform
a set of steps to generate an OAuth2 token.

Robert

Re: Making GNUS continue to work with Gmail

[Cesar Crusius]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

Richard Stallman <rms@gnu.org> writes:

>> It looks like this approach keeps popping up as a "possible
>> solution," so I'll just point out again that this is _already
>> implemented_ in the package above, and is being used by various people
>> to make Gnus work with Gmail and XOAuth2. The discussion here is about
>> how to _avoid_ having to do that.
>
> What IS "this approach"?  Does it get a key that GNUS can use for everyone?
> Does it have each user get a key from Google?

Others already replied, but in any case: the approach I and Lars were replying to and was quoted in my message, namely

>>> Yeah, we could just use that and tell the users to "just" register their
>>> own developer accounts at Google and then put the keys somewhere.  It's
>>> a really really horrid experience to go through, though, and Google will
>>> sic an API compliancy review at the users at random.

... so each user gets a key from Google. The procedure for doing so is documented in the auth-source-xoauth2 package. The only difference between this and the "one key GNUS can use for everyone" approach is that the latter requires (a) an official, Google-approved, GNUS/Emacs app registered from which keys can be shared, and (b) a key sharing mechanism.

From what I've seen from Kmail/Kontact/KPim/etc replies, (a) and (b) is exactly what they are doing, and there's no way around this. The only question is how to achieve those in a way that is compatible with both Google terms and FSF requirements, if there is such a way. Thunderbird "achieves" (b) by having "secret" keys in source code. I don't know what the K* applications do, it did not seem to be specified in their discussions.

In any case, (b), which seems to be the unsolvable puzzle, isn't even worth pursuing if (a) is not doable under FSF requirements, and that is something that only somebody from the FSF can determine.

Looks to me like the most direct course of action here would be for somebody from the FSF to contact *Google themselves* and ask them for guidance on how to make libre software make use of OAuth2 authentication. They may say "can't be done, we won't allow it," but at least the discussion will have an official resolution then and there.

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >     Richard> Does it have each user get a key from Google?

  > The latter. Basically each user has to log in to the google developer
  > 'console' with a web browser and register themselves, and then perform
  > a set of steps to generate an OAuth2 token.

I posted, around a week ago, why that is a bad approach
(not merely inconvenient).

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> > The latter. Basically each user has to log in to the google developer 
> > 'console' with a web browser and register themselves, and then perform 
> > a set of steps to generate an OAuth2 token.
>
> I posted, around a week ago, why that is a bad approach (not merely 
> inconvenient).
>

I'm not sure to what message you refer, but I guess it is the following 
one, dated from August 7th:

>
> Does that web page function using nonfree software?  (Javascript code, 
> for instance?)  Knowing Google, I suspect that it does.
>
> If so, we cannot distribute that function, or suggest to users that they 
> use that page, or have code in Emacs which presumes that they do.
>
> This is a fundamental moral principle of the GNU Project: we hold that 
> running a nonfree program is never a legitimate solution to any problem.
>
> We cannot impose that principle on anyone, and we do not try; but we 
> have a duty not to speak in a way that contradicts it.
>
> It might be possible to write free code which talks to that page using 
> some (perhaps undocumented) API and avoids that issue. That would be 
> good.
>

This is not possible.  There are only two solutions (each user creates 
their own OAuth credentials as if they were a developer of a different 
app, or the developer creates OAuth credentials and shares it with all 
users of the app), but in both cases this will involve nonfree software, 
by the user in the first case and by the developer _and_ the user in the 
second case.

With the solution used by Kmail, Thunderbird and others, when a user adds 
a Google account to their mail client, a Google login page is opened in a 
browser, on which they indicate their login and password.  This page is 
the https://accounts.google.com page, and it uses nonfree JavaScript code.

As you write, it might be possible, at least in theory, to write free code 
which would behave as if it were a browser, thereby avoiding to run the 
nonfree code from Google.  But this would be very hard to do, and it would 
be a fragile solution, because this code is itself not on API, so Google 
is free to change it at any time.  Moreover Google has likely implemented 
ways to detect on their side that it is indeed their code that is run in a 
compatible browser, and to trigger a CAPTCHA request when this is not the 
case.

Gregory

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

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

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Uwe Brauer <oub@mat.ucm.es> writes:
>> 
>>> Yeah, we could just use that and tell the users to "just" register their
>>> own developer accounts at Google and then put the keys somewhere.  It's
>>> a really really horrid experience to go through, though, and Google will
>>> sic an API compliancy review at the users at random.
>>> 
>>> What's about the approach recommended by a mutt user
>>> 
>>> https://luxing.im/mutt-integration-with-gmail-using-oauth/
>>> 
>>> Could that somehow be used for Gnus?
>> 
>> That's the approach you quoted me describing.  :-)

> ... and the approach _already implemented_ by auth-source-xoauth2, which works for Gnus and anything else using auth-source in Emacs:

> https://github.com/ccrusius/auth-source-xoauth2

> (There is some hackery involved in `auth-source-xoauth2-enable` in order to make the protocol work for IMAP/SMTP.)

> It looks like this approach keeps popping up as a "possible solution,"
> so I'll just point out again that this is _already implemented_ in the
> package above, and is being used by various people to make Gnus work
> with Gmail and XOAuth2. The discussion here is about how to _avoid_
> having to do that.

Did you do that? Or do you know somebody who did this. Anybody has an
example?
I'd like to test it.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden]

On 14/08/2020 11:13, Lars Ingebrigtsen wrote:

>> *2. What Thunderbird does data point, and not just a google problem:
> [...]
>> Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft
>>
>> https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51
> 
> I guess it would be rude for Emacs to just use those credentials.  :-)
> 

Heh. Considering it for a sec, even if "borrowing" such other known 
client id and impersonating them is technically possible (in rough 
hypothetical, haven't looked what thunderbird registered in depth, 
particularly its redirect), it is not really viable in terms of ordinary 
user expectations: users would then presumably be asked a very confusing 
and suspicious "mozilla thunderbird wants access to your gmail email 
account, allow?" or something along those lines in their browser during 
the rfc8252 flow (if implemented) in what is actually a gnu emacs sign 
in, and an attentive user would presumably immediately abort and worry.

Does remind me that different emacs-external elisp packages available 
from melpa etc. can (and might well already) have different client ids 
for various providers statically embedded for their own use. Of course 
that's pretty much just Not GNU's Problem in legal terms so long as they 
don't make their way into official emacs (+elpa) sources, just wanted to 
make a pedantic point that it's not 1:1, different things happening to 
run within a user's emacs can certainly have distinct client 
registrations even for the same provider at least technically.

Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden]

On 15/08/2020 20:39, Cesar Crusius wrote:

>  From what I've seen from Kmail/Kontact/KPim/etc replies, (a) and (b) is exactly what they are doing, and there's no way around this. The only question is how to achieve those in a way that is compatible with both Google terms and FSF requirements, if there is such a way. Thunderbird "achieves" (b) by having "secret" keys in source code. I don't know what the K* applications do, it did not seem to be specified in their discussions.
> 

For the morbidly curious like myself:

N.B. I'm far from familiar with the sprawling KDE sources in general, 
but it's freely licensed (LGPL), so had a quick look.

Anyway, their source-embedded static values were trivial to locate at 
time of writing:

https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/imap/gmailpasswordrequester.cpp#L16

https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/google-groupware/googlesettings.cpp#L143

https://invent.kde.org/pim/kmailtransport/-/blob/master/src/kmailtransport/plugins/smtp/smtpjob.cpp#L32

The referenced kde KGAPI component (implements enough oauth2 to work 
against google) appears to be use the 
spawn-transient-http-server-on-localhost redirect_uri approach/trick to 
pick up the authorization code (to convert to access+refresh tokens with 
second request).  Don't seem to be doing code_challenge/code_verifier 
i.e. pkce /rfc7636 yet (presumably should). To make the request they 
actually currently appear to use / still use embedded webview, not 
delegating to user's browser, in contrast to recent 
https://tools.ietf.org/html/rfc8252#section-8.12

(skipping pkce and embedded webview may be "grandfathered in", can well 
imagine google and other providers frowning on it for newly-issued app 
client ids)

https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget.cpp#L100

code req to auth endpoint

https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget.cpp#L121

code response receipt

https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/ui/authwidget_p.cpp#L277

code->token req to token endpoint

https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/private/newtokensfetchjob.cpp#L88

token response processed

https://invent.kde.org/pim/libkgapi/-/blob/master/src/core/private/newtokensfetchjob.cpp#L124

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > With the solution used by Kmail, Thunderbird and others, when a
  > user adds a Google account to [per] mail client, a Google login
  > page is opened in a browser, on which [person indicates per]
  > login and password.  This page is the https://accounts.google.com
  > page, and it uses nonfree JavaScript code.

Thank you for posting this information.  About use of Google services
I know only what people tell me.

Let's look at the implications of this for the situation we are in.

First, a question: does creating a Gmail account go through some
Google page (perhaps the same one) that also requires nonfree
JavaScript code?

If so, then anyone who starts using Gmail in the future will have had
to run that same nonfree software to start.  It would be wrong to
steer anyone in that direction, but when users do so on their own
initiative it is not our responsibility.  (If someone decides to use
Gmail, that won't be because we suggested it.)

So I think it would be acceptable for GNUS to have an app key such
that, IF a user does these things with Gmail, per Gmail account works
with GNUS.  But it would not be acceptable for the code of GNUS or the
documentation of GNUS to steer users towards doing those operations
with Gmail.

I have a hunch there may be a bounded but perhaps large set of people
who started using Gmail at a time when it did not require running
nonfree software to make the account.  It looks like Google is going
to force them to run nonfree software at least once or else stop using
Gmail.  That is injustice, and too bad, but it's Google's injustice,
not ours.  It does not rasie an ethical issue about our conduct.

I've made a number of suppositions here.  Are any of them mistaken?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re:Re: Making GNUS continue to work with Gmail

[范凯]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

Is it possiable to just use the application specific password?


https://support.google.com/accounts/answer/185833#app-passwords



Thanks,
Kai


















At 2020-08-15 17:45:16, "Gregory Heytings via \"Emacs development discussions.\"" <emacs-devel@gnu.org> wrote:
>
>>
>> What IS "this approach"?  Does it get a key that GNUS can use for 
>> everyone? Does it have each user get a key from Google?
>>
>
>For the sake of clarity, there are two possible approaches:
>
>1. Each user creates its own OAuth credentials, and uses them to access 
>their own Google account.  From the point of view of Google, this is as if 
>each user created its own app.  This is the solution chosen by Mutt and 
>others.  Its main advantage is that the process is immediate (it takes 
>only a few minutes).  Its main drawback is that it is a rather complex 
>process.
>
>2. The developer creates OAuth credentials, and includes them in the 
>program.  From the point of view of Google, only one app exists, with many 
>users.  This is the apparently the solution chosen by Kmail, Thunderbird 
>and others.  Its main advantage is that it makes the process very simple 
>(almost transparent) for users: when they add a Google account to their 
>mail client, a Google page is opened in a browser, they indicate their 
>login and password, and that's all.  Its main drawback is that it is a 
>long process, because Google has to review and approve the app.  It 
>requires at least: (1) having a domain name for the app, (2) writing a 
>privacy policy for the app, (3) creating a video that demonstrates the 
>OAuth grant process in the app, (4) submitting the app for verification to 
>Google, and waiting that it be approved.
>
>For the sake of completeness, there is in fact a third possible approach, 
>which cannot be used by regular Gmail users:
>
>3. If your Google account is a G Suite account (either a business one or 
>an education one), that is, if your email is managed by Google but your 
>email address does is not an @gmail.com address, then the G Suite 
>administrator can do the process (1) above once for all users of a given 
>mail client.  That is, the mail client is approved once for all users of 
>that domain without the need of a review by Google.
>
>Gregory

[-- Attachment #2: Type: text/html, Size: 3103 bytes --]

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> > With the solution used by Kmail, Thunderbird and others, when a user 
> > adds a Google account to [per] mail client, a Google login page is 
> > opened in a browser, on which [person indicates per] login and 
> > password.  This page is the https://accounts.google.com page, and it 
> > uses nonfree JavaScript code.
>
> Thank you for posting this information.  About use of Google services I 
> know only what people tell me.
>
> Let's look at the implications of this for the situation we are in.
>

In short: it's a moral dilemma.

Again there are only two possibilities: either (1) each user creates their 
own OAuth credentials, as if they were a developer of a different app, or 
(2) the developer creates OAuth credentials and shares it with all users 
of the app.  Neither of these two solutions seem compatible with the GNU 
ethical principles.

>
> First, a question: does creating a Gmail account go through some Google 
> page (perhaps the same one) that also requires nonfree JavaScript code?
>

Yes.

>
> If so, then anyone who starts using Gmail in the future will have had to 
> run that same nonfree software to start.
>

"will have to run nonfree software to start": yes.

"will have to run _that same_ nonfree software to start": no.  For 
solution (1), it is necessary to use https://console.developers.google.com 
to "create" an app (from Google's point of view), and this page runs a 
visibly different software.  So solution (1) is not only impractical, but 
documenting it does not seem to be compatible with the GNU ethical 
principles, at it would mean to suggest users to run a nonfree software 
they would not have run if they had not been told to do so.

>
> So I think it would be acceptable for GNUS to have an app key such that, 
> IF a user does these things with Gmail, per Gmail account works with 
> GNUS.
>

I fear not.  Solution (2), which is used by Kmail and others, does not 
seem to be compatible with the GNU ethical principles either, as it would 
require someone from GNU, or on behalf of GNU, to use 
https://console.developers.google.com to create AOuth credentials to 
include them in the sources of GNUS.  In other words, to run nonfree 
JavaScript code.

(Note that doing this (that is, including an app key in free software) 
also violates Google's terms of service.  But apparently Google tolerates 
that these terms are violated by Kmail, Thunderbird and others, so would 
presumably also tolerate that they be violated by GNUS.)

Gregory

Re: Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Mon, Aug 17, 2020 at 02:00:41PM +0800, 范凯 wrote:
> Is it possiable to just use the application specific password?

This is Gregory's option (2), right?

He explains the drawbacks of this approach: Google doesn't *want*
that the app's users see the password. But the app is free software,
so *we* want that the users see everything in the app.

I think this goes deeper: Google wants to be in control and we
want the user to be in control. This leads to a conflict whenever
the user is not Google.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> He explains the drawbacks of this approach: Google doesn't *want* that 
> the app's users see the password. But the app is free software, so *we* 
> want that the users see everything in the app.
>

That's what Google's official terms of service state.  But in practice 
this is not enforced, Google tolerates that free software projects violate 
that specific point of their TOS.  Otherwise Kmail, Thunderbird and others 
would not work with Gmail.  They do work with Gmail, because they include 
OAuth credentials in their source code.  For that matter, Google knows 
very well that this is nothing but "security through obscurity", given 
that OAuth credentials are at least embedded in the program binary (or 
perhaps stored somewhere else and read by the program).

Gregory

Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden]

On 17/08/2020 09:23, tomas@tuxteam.de wrote:
> On Mon, Aug 17, 2020 at 02:00:41PM +0800, 范凯 wrote:
>> Is it possiable to just use the application specific password?
> 
> This is Gregory's option (2), right?
> 
No,  "app specific passwords" are a separate end-user facility google in 
particular currently offers (other providers certainly may not allow 
anything similar), where the end-user can generate secondary passwords 
distinct from their main one, for use with non-oauth2-supporting apps 
that use traditional username+password auth methods.

Using their "app specific passwords" facility requires enabling the "2 
step verification" facility with its own issues*, and then disables the 
ability to use the general "less secure apps" (google terminology) 
facility that allows traditional username/user-main-password auth.

App specific passwords are relatively complex and manual for the 
end-user to manage, and google may withdraw the facility one day too 
(well that surely applies to anything google does anyway).

Personally I have no idea from the various recent announcements around 
"less secure apps" how long they will continue to allow such "app 
specific passwords" in the sense of such username/app-specific-password 
plain auth (at the protocol level, not any out of band 2-step 
shenanigans) even after disallowing overall "less secure apps" (google 
terminology) in the sense of username/user-main-password plain auth.

I expect they would continue ...in the short term... to avoid completely 
locking out users of old mobile devices if nothing else.  Even so, once 
their usage stats drop below some level, they may move to phase them out 
- they're clearly annoying, error-prone and complex for users to manage 
compared to fully-implemented oauth2 flow (user-exposed complexity of 
manual token fetches and stuff is not normal even if emacs users are 
currently doing it)


(* perhaps not because it's bad in principle, simple password auth has 
its known issues, but because google initially requires and encourages a 
notoriously weak phone-sms method by default (subject to recent and 
high-profile attacks by "sim swap" social engineering and the like at 
other providers). Though you can configure e.g. totp instead afterward [1])


[1] https://support.google.com/accounts/thread/5185475?hl=en

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>> With the solution used by Kmail, Thunderbird and others, when a
>> user adds a Google account to [per] mail client, a Google login
>> page is opened in a browser, on which [person indicates per]
>> login and password.  This page is the https://accounts.google.com
>> page, and it uses nonfree JavaScript code.

> Thank you for posting this information.  About use of Google services
> I know only what people tell me.

> Let's look at the implications of this for the situation we are in.

> First, a question: does creating a Gmail account go through some
> Google page (perhaps the same one) that also requires nonfree
> JavaScript code?

> If so, then anyone who starts using Gmail in the future will have had
> to run that same nonfree software to start.  It would be wrong to
> steer anyone in that direction, but when users do so on their own
> initiative it is not our responsibility.  (If someone decides to use
> Gmail, that won't be because we suggested it.)

> So I think it would be acceptable for GNUS to have an app key such
> that, IF a user does these things with Gmail, per Gmail account works
> with GNUS.  But it would not be acceptable for the code of GNUS or the
> documentation of GNUS to steer users towards doing those operations
> with Gmail.

> I have a hunch there may be a bounded but perhaps large set of people
> who started using Gmail at a time when it did not require running
> nonfree software to make the account.  It looks like Google is going
> to force them to run nonfree software at least once or else stop using
> Gmail.  That is injustice, and too bad, but it's Google's injustice,
> not ours.  It does not rasie an ethical issue about our conduct.

> I've made a number of suppositions here.  Are any of them mistaken?

Mistaken not, but I should add one scenario that you did not cover.
Users of academic institutions[1] found them self from one day to the
other, with their email accounts transferred to G-Suite (that this the
professional Gmail service), without doing anything at all.

This is the issue which bothers me most, because free, personal
GMail accounts give me the freedom to change or abort them. Official
workplace email do not give me that freedom.



Footnotes:
[1]  unfortunately I don't know how many


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Mon, Aug 17, 2020 at 12:30:41PM +0000, Gregory Heytings via Emacs development discussions. wrote:
> 
> >
> >He explains the drawbacks of this approach: Google doesn't *want*
> >that the app's users see the password. But the app is free
> >software, so *we* want that the users see everything in the app.
> >
> 
> That's what Google's official terms of service state.  But in
> practice this is not enforced [...]

I think this is what's normally depicted in the "boiling frog"
metaphor [1]. If Google makes the transition too abruptly, they
may lose some users. If they do it slowly, the users will follow
along, albeit grumbling.

Cheers
[1] https://en.wikipedia.org/wiki/Boiling_frog
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden]

On 17/08/2020 08:51, Gregory Heytings via Emacs development discussions. 
wrote:

> (Note that doing this (that is, including an app key in free software) 
> also violates Google's terms of service.  But apparently Google 
> tolerates that these terms are violated by Kmail, Thunderbird and 
> others, so would presumably also tolerate that they be violated by GNUS.)
>

Well, they're legal terms not program code.  Apart from them just 
tolerating/overlooking it, things can also happen between parties under 
terms different to or supplemental to some generic published standard 
terms, Cesar's point that the FSF could talk to Google about it on an 
official basis certainly stands.

The legal side may just not have caught up with evolving native app / 
public client not-a-secret usage anyway, the terms seem more suited to 
traditional server-side web apps, still a common use case for oauth2 
(contrast e.g. [1] and [2]).

I expect it's actually Mozilla and KDE representatives that self-service 
manage their respective registrations via the relevant google api 
console, not Google employees, in their cases,  but it is also possible 
to imagine (however unlikely in practice) Google and the FSF taking a 
different approach and agreeing to a Google employee instead managing 
and issuing on their side some  client id(s) for various uses to the FSF 
i.e. rather than an FSF representative agreeing to the generic terms and 
logging in and self-service managing clients (though that has associated 
loss of self-service control e.g. branding during the auth flow etc).

Then sending the client to the FSF under some sort of alternative legal 
terms along the lines of "actually this here client id can be embedded 
in emacs gnus sources under the GPL, it's fine, despite what those 
generic terms say, Note it will only actually work for oauth2 if auth 
code with pkce and a localhost redirect_uri flow is used. And google may 
also temporarily or permanently cease recognising this client id at any 
time for any reason, and a new client id may or may not be issued".  A 
Google employee contributing an actual source code patch with such a 
client id embedded would make that rather on-the-record.  Not saying 
that is especially desirable or google would be likely to go for that 
option anwyay, just seems another possible in principle thing worth 
mentioning.


[1] https://auth0.com/docs/flows/authorization-code-flow

"""
Because regular web apps are server-side apps where the source code is 
not publicly exposed, they can use the Authorization Code Flow (defined 
in OAuth 2.0 RFC 6749, section 4.1), which exchanges an Authorization 
Code for a token. Your app must be server-side because during this 
exchange, you must also pass along your application's Client Secret, 
which must always be kept secure, and you will have to store it in your 
client.
"""

[2] 
https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce

"""
When public clients (e.g., native and single-page applications) request 
Access Tokens, some additional security concerns are posed that are not 
mitigated by the Authorization Code Flow alone. This is because:
Native apps Cannot securely store a Client Secret. Decompiling the app 
will reveal the Client Secret, which is bound to the app and is the same 
for all users and devices.

[...]

To mitigate this, OAuth 2.0 provides a version of the Authorization Code 
Flow which makes use of a Proof Key for Code Exchange (PKCE) (defined in 
OAuth 2.0 RFC 7636).
"""

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

Uwe Brauer:
>
> Mistaken not, but I should add one scenario that you did not cover. 
> Users of academic institutions[1] found them self from one day to the 
> other, with their email accounts transferred to G-Suite (that this the 
> professional Gmail service), without doing anything at all.
>

These users are facing a much simpler problem.  They only need to ask the 
G Suite administrator to approve their app, and it will be immediately 
approved for all users of the domain.  Given that they did not choose to 
use G Suite, I believe asking this and using the app key provided by the 
administrator does not violate the GNU ethical principles.

Gregory

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

>>> "Edd" == Emacs development discussions <Gregory> writes:

   > Uwe Brauer:
   >> 
   >> Mistaken not, but I should add one scenario that you did not cover.
   >> Users of academic institutions[1] found them self from one day to
   >> the other, with their email accounts transferred to G-Suite (that
   >> this the professional Gmail service), without doing anything at all.
   >> 

   > These users are facing a much simpler problem.  They only need to ask
   > the G Suite administrator to approve their app, and it will be
   > immediately approved for all users of the domain.  Given that they did
   > not choose to use G Suite, I believe asking this and using the app key
   > provided by the administrator does not violate the GNU ethical
   > principles.

https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html

I am not sure that this is correct:

it says, see point 3.



    1. If you use other apps on iOS or MacOS that access your G Suite
       account information through only a password, most access issues
       can be resolved by removing then re-adding your account. When you
       add it back, make sure to select Google as the account type to automatically use OAuth.

    2. For any other LSA, contact your admin or ask the developer of the
       app you are using to start supporting OAuth.

    3. *If the developer won’t update their app, you will need to switch
       to a client that offers OAuth.*


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]


>
> 2. For any other LSA, contact your admin or ask the developer of the app 
> you are using to start supporting OAuth.
>
> 3. *If the developer won’t update their app, you will need to switch to 
> a client that offers OAuth.*
>

The issue is not whether Gnus supports OAuth.  It does (more precisely, it 
is possible to set up a configuration with which it does).  OAuth is a 
standard.

The issue is how to use OAuth with Google accounts in a way that is 
compatible with the GNU principles.

For the specific case of G Suite accounts, this issue does not exist, 
because there is no need for the user, or for those who created the 
application, to interact with Google: your admin can provide you the 
necessary OAuth credentials.  If you "contact your admin" (see point 2 
above) and convince them to make your mail client an app that users of 
your organization can use to access their G Suite mail account, they 
create a set of OAuth credentials (these are simply two long strings) and 
give them to you (and to other users wishing to use the same mail client). 
You put these credentials in your mail client configuration, and from then 
on it can access your mail account (after going through the OAuth grant 
process with a browser).

Gregory

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > If so, then anyone who starts using Gmail in the future will have had to 
  > > run that same nonfree software to start.
  > >

  > "will have to run nonfree software to start": yes.

  > "will have to run _that same_ nonfree software to start": no.  For 
  > solution (1), it is necessary to use https://console.developers.google.com 
  > to "create" an app

We are miscommunicaing here.  I am talking about option (2), where the
user only has to log in and permit access to per account via the
already-existing app.  (Or at least, that's what I think you said.)

I'm not talking about option (1) since it is totally unacceptable.

  > > So I think it would be acceptable for GNUS to have an app key such that, 
  > > IF a user does these things with Gmail, per Gmail account works with 
  > > GNUS.
  > >

  > I fear not.  Solution (2), which is used by Kmail and others, does not 
  > seem to be compatible with the GNU ethical principles either, as it would 
  > require someone from GNU, or on behalf of GNU, to use 
  > https://console.developers.google.com to create AOuth credentials to 
  > include them in the sources of GNUS.

If done the usual way, this would involve someone's running that
nonfree Javascript code.  But we don't say "GNU developers must never
run a nonfree program to do their work."  Until GCC was working well
enough to host itself forever, I compiled it lots of times with the
nonfree BSD compiler.

What we avoid on principle is the situation where use of our software
depends on running nonfree software.  For one person to run nonfree
software once, to make it unnecessary for others to run it, is the
sort of situation which we consider a legitimate exception.

Also, I am not convinced it has to be done by "someone from [the GNU
Project], or on behalf of [the GNU Project]".  It could be anyone who
wants to keep using GNUS with Gmail (and is willing to sometimes run
Gmail's nonfree JS code).  If someone does this and sends us some data,
we can use it.  If no one does this, well, not working with Gmail isn't
a disaster.

Meanwhile, I wonder if Chris DiBona could let us bypass that nonfree
JS code.  I would guess that what Google really cares about is not
whether we run that JS code, but rather the substance of that request.

This brings me to another issue that may be harder to work around.
What conditions would someone have to agree to when requesting Google's
approval for an app?  There could be something morally unacceptable in
that.  Though it does matter who would have to agree to it.

Here's an idea.  Is it possible to modify Kmail so that it does the
necessary low-level access, and nothing else?  Delete the code for
displaying an editing mail.  This drastically modified version of
Kmail would satisfy Kmail's license.  GNUS and Rmail could use it,
much as they used to use movemail.

Maybe it could be upward compatible with the old movemail.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Given that they did not choose to 
  > use G Suite, I believe asking this and using the app key provided by the 
  > administrator does not violate the GNU ethical principles.

We don't try to tell the public to follow our principles -- that's up
to each person, and we have no authority over their decisions.

What we do tell the public is how their freedom is threatened by
nonfree programs.  Then, if they appreciate the issue, they will take
some steps to defend their freedom, at least partially.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Mistaken not, but I should add one scenario that you did not cover.
  > Users of academic institutions[1] found them self from one day to the
  > other, with their email accounts transferred to G-Suite (that this the
  > professional Gmail service), without doing anything at all.

If we can do something that helps them, we will.  But the main
questions are about what we CAN do.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> > "will have to run _that same_ nonfree software to start": no.  For 
> > solution (1), it is necessary to use 
> > https://console.developers.google.com to "create" an app
>
> We are miscommunicaing here.  I am talking about option (2), where the 
> user only has to log in and permit access to per account via the 
> already-existing app.  (Or at least, that's what I think you said.)
>
> I'm not talking about option (1) since it is totally unacceptable.
>

It was not clear at all until now that option (1) was totally 
unacceptable.

>
> What we avoid on principle is the situation where use of our software 
> depends on running nonfree software.  For one person to run nonfree 
> software once, to make it unnecessary for others to run it, is the sort 
> of situation which we consider a legitimate exception.
>

Okay, I was not aware of that subtlety.

>
> Also, I am not convinced it has to be done by "someone from [the GNU 
> Project], or on behalf of [the GNU Project]".
>

Well, this is what happened for Kmail, Thunderbird and others.  The person 
who applies to have an app approved by Google becomes legally responsible 
of the use of the OAuth credentials received at the end of the process. 
In the case of an app that is used by many people around the world, this 
should be a legal person, not an individual.

Moreover one of the (possible) steps in having Google approve an app is to 
have the code of the app reviewed by security experts, and it is the 
person who applies to have an app approved who has to pay for this. 
Again this cannot be an individual.

Writing the privacy policy is also something that an individual cannot do, 
and that is required by Google.

>
> It could be anyone who wants to keep using GNUS with Gmail (and is 
> willing to sometimes run Gmail's nonfree JS code).  If someone does this 
> and sends us some data, we can use it.
>

Yes, if they agree to take the legal responsibility of the use of these 
credentials, and if they pay if Google wants to have the code of the 
program reviewed by security experts.

>
> This brings me to another issue that may be harder to work around. What 
> conditions would someone have to agree to when requesting Google's 
> approval for an app?  There could be something morally unacceptable in 
> that.  Though it does matter who would have to agree to it.
>

I gave some indications above.  But I'm not a lawyer.

>
> Here's an idea.  Is it possible to modify Kmail so that it does the 
> necessary low-level access, and nothing else?  Delete the code for 
> displaying an editing mail.  This drastically modified version of Kmail 
> would satisfy Kmail's license.  GNUS and Rmail could use it, much as 
> they used to use movemail.
>

It's an idea indeed, but I fear it is not a good one.  It means at least 
that:

(1) The KDE foundation would become legally responsible of the use of the 
OAuth credentials by people outside of the KDE project.  They would most 
likely officially ask you to stop using their credentials.  If you did not 
agree, the risk for them is that their credentials would be revoked by 
Google.

(2) During the OAuth grant process (when a user adds an account to their 
email client), the OAuth credentials are used to identify the app.  In 
other words, with your idea the Gnus user would be presented with a screen 
which says "The app Kmail wants to access your email.  Approve?".  A Gnus 
user would not know what "Kmail" is, or at least would be reluctant to 
click on "Approve".

Gregory

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, this is what happened for Kmail, Thunderbird and others.  The person 
  > who applies to have an app approved by Google becomes legally responsible 
  > of the use of the OAuth credentials received at the end of the process. 
  > In the case of an app that is used by many people around the world, this 
  > should be a legal person, not an individual.

I don't follow that.  "Should" stands for a moral imperative, but I don't
see where the imperative would come from here.  Perhaps you're basing
the conclusion on reasons I don't know about.

  > Yes, if they agree to take the legal responsibility of the use of these 
  > credentials, and if they pay if Google wants to have the code of the 
  > program reviewed by security experts.

I am completely lost here.  What legal responsibility is involved?

I've asked for someone to please tell me, in brief terms, the concrete
reqwuirements for issuing an app key to something like GNUS, but I have not
seen a reply stating them.

People have sent me URLs pointing at what I suspect are long texts,
some of which might answer this question.  The obvious way for me to
find out those answers is to go read those.  Obvious, but not
feasible.  I am totally overloaded, and (unusually) I even have
deadlines.  I can't do that the inefficient way.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
>> Yes, if they agree to take the legal responsibility of the use of these 
>> credentials, and if they pay if Google wants to have the code of the 
>> program reviewed by security experts.
>
> I am completely lost here.  What legal responsibility is involved?
>

This is an answer that developers cannot give you.  It's a question that 
only a lawyer can answer.  But I at least would not agree to personally 
take the risk of being sued by Google for having knowingly violated their 
terms of service, even if Google tolerates (at the moment at least) that 
free software projects violate these TOS.  I observe that this is what 
happened in similar projets, e.g. Kmail: it's not an individual who has 
submitted the app for verification by Google, but a legal person, KDE e.V.

Violating these TOS by making the OAuth credentials public (which is what 
happens in a free software project) can have consequences, for example if 
a malicious person uses them in their own app to fraudulently gain access 
to Google accounts.

>
> I've asked for someone to please tell me, in brief terms, the concrete 
> reqwuirements for issuing an app key to something like GNUS, but I have 
> not seen a reply stating them.
>

Google's terms of service for OAuth services are available at 
https://developers.google.com/terms .  Only a lawyer can tell you in brief 
terms what the concrete requirements are.

I've just read them again, and it seems to me that:

- Paragraph 4.a.1, which states that "you will not create an API Client 
that functions substantially the same as the APIs and offer it for use by 
third parties", expressly prohibits your idea of creating a "modif[ied] 
Kmail so that it does the necessary low-level access, and nothing else".

- Paragraph 4.b.1, which states that "You will keep your credentials 
confidential and make reasonable efforts to prevent and discourage other 
API Clients from using your credentials. Developer credentials may not be 
embedded in open source projects." prohibits the use of OAuth credentials 
in free software projects.  As I wrote above (and earlier), Google 
tolerates (at the moment) that this specific point of their TOS is 
violated.  But that doesn't mean that violating them is without legal 
risk.

- Paragraph 9.c list the legal risks: "Unless prohibited by applicable 
law, if you are a business, you will defend and indemnify Google, and its 
affiliates, directors, officers, employees, and users, against all 
liabilities, damages, losses, costs, fees (including legal fees), and 
expenses relating to any allegation or third-party legal proceeding to the 
extent arising from: - your misuse or your end user's misuse of the APIs; 
- your violation or your end user's violation of the Terms; or - any 
content or data routed into or used with the APIs by you, those acting on 
your behalf, or your end users."  Of course an individual person is not a 
business, but nobody is completely independent, and I'd guess that Google 
would seek redress against that person's employer for example.

What I wrote above is nothing but my understanding.  Again, only a lawyer 
can tell you what these TOS concretely imply.

Gregory

Re: Making GNUS continue to work with Gmail

[Arthur Miller]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>>
>>> Yes, if they agree to take the legal responsibility of the use of these
>>> credentials, and if they pay if Google wants to have the code of the program
>>> reviewed by security experts.
>>
>> I am completely lost here.  What legal responsibility is involved?
>>
>
> This is an answer that developers cannot give you.  It's a question that only a
> lawyer can answer.  But I at least would not agree to personally take the risk
> of being sued by Google for having knowingly violated their terms of service,
> even if Google tolerates (at the moment at least) that free software projects
> violate these TOS.  I observe that this is what happened in similar projets,
> e.g. Kmail: it's not an individual who has submitted the app for verification by
> Google, but a legal person, KDE e.V.
>
> Violating these TOS by making the OAuth credentials public (which is what
> happens in a free software project) can have consequences, for example if a
> malicious person uses them in their own app to fraudulently gain access to
> Google accounts.
>
>>
>> I've asked for someone to please tell me, in brief terms, the concrete
>> reqwuirements for issuing an app key to something like GNUS, but I have not
>> seen a reply stating them.
>>
>
> Google's terms of service for OAuth services are available at
> https://developers.google.com/terms .  Only a lawyer can tell you in brief terms
> what the concrete requirements are.
>
> I've just read them again, and it seems to me that:
>
> - Paragraph 4.a.1, which states that "you will not create an API Client that
>   functions substantially the same as the APIs and offer it for use by third
>   parties", expressly prohibits your idea of creating a "modif[ied] Kmail so
>  that it does the necessary low-level access, and nothing else".
>
> - Paragraph 4.b.1, which states that "You will keep your credentials
>   confidential and make reasonable efforts to prevent and discourage other API
>   Clients from using your credentials. Developer credentials may not be embedded
>   in open source projects." prohibits the use of OAuth credentials in free
>   software projects.  As I wrote above (and earlier), Google tolerates (at the
>   moment) that this specific point of their TOS is violated.  But that doesn't
>   mean that violating them is without legal risk.
>
> - Paragraph 9.c list the legal risks: "Unless prohibited by applicable law, if
>   you are a business, you will defend and indemnify Google, and its affiliates,
>   directors, officers, employees, and users, against all liabilities, damages,
>   losses, costs, fees (including legal fees), and expenses relating to any
>   allegation or third-party legal proceeding to the extent arising from: - your
>   misuse or your end user's misuse of the APIs; - your violation or your end
>   user's violation of the Terms; or - any content or data routed into or used
>   with the APIs by you, those acting on your behalf, or your end users."  Of
>   course an individual person is not a business, but nobody is completely
>   independent, and I'd guess that Google would seek redress against that
>  person's employer for example.
>
> What I wrote above is nothing but my understanding.  Again, only a lawyer can
> tell you what these TOS concretely imply.
>
> Gregory

Just as a curiosa: have you guys thought about asking Google for
help/clarification? Can't FSF send a mail to Google lawyers/devs and ask
what has to be done get FSF/GNU software work with Google services? Of
course there is no sure that Google will answer in any meaningful way if
at all, but have you tried?

Re: Making GNUS continue to work with Gmail

[Gregory Heytings via Emacs development discussions.]

>
> Just as a curiosa: have you guys thought about asking Google for 
> help/clarification? Can't FSF send a mail to Google lawyers/devs and ask 
> what has to be done get FSF/GNU software work with Google services? Of 
> course there is no sure that Google will answer in any meaningful way if 
> at all, but have you tried?
>

Yes, that's what I and others suggested some two weeks ago.  (I also 
provided a contact at Google.)

OTOH, it's already clear that Google will not adapt their terms to please 
the GNU Project or the FSF.  Apple, Microsoft, Thunderbird, Kmail, Mutt, 
and so forth are all subjected to those same terms.

Gregory

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I am completely lost here.  What legal responsibility is involved?
  > >

  > This is an answer that developers cannot give you.  It's a question that 
  > only a lawyer can answer.

I think we are failing to communicate.  You seem to have got an idea
that there is some legal responsibility involved.  Unless you consulted
a lawyer, you must have got some idea from published information.

I don't have time to peruse the various pages what Google has
published hoping to find the crucial passages.  I asked people to show
me the specific requirements that are crucial for this scenario.

You have showed me some passages of that text.  If you send me the
whole text that you got them out of, that would help me.

Maybe someone already sent me that text.  I am so behind on email that
I might have received a few days ago and not yet seen it.

I am trying to do many jobs at once.

  > Google's terms of service for OAuth services are available at 
  > https://developers.google.com/terms .

I will fetch that page and see what I get.

  > take the risk of being sued by Google for having knowingly violated their 
  > terms of service, even if Google tolerates (at the moment at least) that 
  > free software projects violate these TOS.

A priori, I doubt there is any real risk, beyond the possibility
Google would invalidate the app key.  But that is a question I can
discuss with a lawyer if it comes up.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Monday, 17 Aug 2020 at 17:02, Uwe Brauer wrote:
> Users of academic institutions[1] found them self from one day to the
> other, with their email accounts transferred to G-Suite (that this the
> professional Gmail service), without doing anything at all.

Or to Microsoft's office365 which is bad in similar ways as
G-Suite.  And gnus, from what I hear, is going to have the same problem
when they stop IMAP/POP access this autumn (northern hemisphere).

I have no idea what solutions may exist or may be possible for
Office365.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Pierre Téchoueyres]

Le mercredi 26 août 2020 à 15:44, Eric S Fraga <e.fraga@ucl.ac.uk> a écrit :
> On Monday, 17 Aug 2020 at 17:02, Uwe Brauer wrote:
>> Users of academic institutions[1] found them self from one day to the
>> other, with their email accounts transferred to G-Suite (that this the
>> professional Gmail service), without doing anything at all.
>
> Or to Microsoft's office365 which is bad in similar ways as
> G-Suite.  And gnus, from what I hear, is going to have the same problem
> when they stop IMAP/POP access this autumn (northern hemisphere).
>
> I have no idea what solutions may exist or may be possible for
> Office365.

Hi evreryone,

For what it's worth: I use Davmail (http://davmail.sourceforge.net/)
which is GPL v2.
TD;LR : its a sort of translator or proxy which transform Exchange
server's protocols into standard ones (smtp, imap / pop, ldap, carddav).

Pierre.

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Or to Microsoft's office365 which is bad in similar ways as
  > G-Suite.  And gnus, from what I hear, is going to have the same problem
  > when they stop IMAP/POP access this autumn (northern hemisphere).

THat is rather terse -- could you spell out your concern carefully?
Who is doing what?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Wednesday, 26 Aug 2020 at 22:22, Pierre Téchoueyres wrote:
> For what it's worth: I use Davmail (http://davmail.sourceforge.net/)
> which is GPL v2.

Thank you.  I tried davmail in the past but it didn't work well with
Office365 but this was more due to network issues I was having at the
time...  I'll keep this in mind when/if MS change their access options
for Office365.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Wednesday, 26 Aug 2020 at 22:50, Richard Stallman wrote:
> THat is rather terse -- could you spell out your concern carefully?
> Who is doing what?

Microsoft:

        "Today, we are announcing that on October 13th, 2020 we will
        stop supporting and retire Basic Authentication for Exchange
        Active Sync (EAS), Post Office Protocol (POP), Internet Message
        Access Protocol (IMAP), and Remote PowerShell (RPS) in Exchange
        Online. This means that new or existing applications using one
        or more of these API’s/protocols will not be able to use Basic
        Authentication when connecting to Office 365 mailboxes or
        endpoints and will need to update how they authenticate."

https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/

"Today" being 20 September 2019, according to the web page.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Thu, Aug 27, 2020 at 12:28:20PM +0100, Eric S Fraga wrote:
> On Wednesday, 26 Aug 2020 at 22:50, Richard Stallman wrote:
> > THat is rather terse -- could you spell out your concern carefully?
> > Who is doing what?
> 
> Microsoft:
> 
>         "Today, we are announcing that on October 13th, 2020 we will
>         stop supporting and retire Basic Authentication for Exchange
>         Active Sync (EAS), Post Office Protocol (POP), Internet Message
>         Access Protocol (IMAP), and Remote PowerShell (RPS) in Exchange
>         Online. This means that new or existing applications using one
>         or more of these API’s/protocols will not be able to use Basic
>         Authentication when connecting to Office 365 mailboxes or
>         endpoints and will need to update how they authenticate."

FWIW, I had both mutt and fetchmail working against an Exchange server
with NTLM (yuck!) authentication. No idea whether Microsoft plans to
(or has, already) phase out NTLM.

Cheers

Microsoft "boiling frogs since 1975"

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Making GNUS continue to work with Gail

[Eric S Fraga]

On Thursday, 27 Aug 2020 at 14:03, tomas@tuxteam.de wrote:
> FWIW, I had both mutt and fetchmail working against an Exchange server
> with NTLM (yuck!) authentication. No idea whether Microsoft plans to
> (or has, already) phase out NTLM.

If gnus doesn't have support for Office365 when the authentication
procedures change (and it's unlikely it will), I will redirect all my
Office365 work email to a friendlier mail server and use gnus splitting
and other bits to manage.  It seems that SMTP will not be affected so I
will still be able to send emails through my work email.

> Microsoft "boiling frogs since 1975"

Yup.  

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Andrew Cohen]

Microsoft has deferred retiring Basic Authentication for existing
customers until the second half of 2021 due to covid-19. New customers,
or those with no recorded usage, will have Basic Authentication disabled
as scheduled, October 2020.

https://developer.microsoft.com/en-us/office/blogs/deferred-end-of-support-date-for-basic-authentication-in-exchange-online/


For what its worth the outlook issues are similar to (or the same as)
gmail: registering a client with MS (or google) and then using a
potentially problematic web page to obtain a refresh-token. Once this is
done it is quite easy (in both gmail and outlook) to use the oauth2.el
library to authenticate.

In case anyone is interested in the details:

1. Refreshing the access-token using the oauth2.el library didn't work
    at first. Turns out MS forbids including the client_secret in the
    params list, while google requires it. I've changed oauth2.el to
    handle this trivial issue.

2. There are a several packages floating around to make this work but I
    realized it can be done with existing mechanisms with one minor
    change to auth-source.el (which I just pushed to master), allowing
    the plstore backend to store a function that retrieves the password
    rather than the password itself. Then setting this slot to the
    function from oauth2.el that refreshes the token
    makes everything just work.

If anyone wants more details let me know.

Best,
Andy

Re: Making GNUS continue to work with Gmail

[Eric S Fraga]

On Thursday, 27 Aug 2020 at 20:30, Andrew Cohen wrote:
> Microsoft has deferred retiring Basic Authentication for existing
> customers until the second half of 2021 due to covid-19. 

Ah, thank you for this!  I can relax for a while then. :-)

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For what its worth the outlook issues are similar to (or the same as)
  > gmail: registering a client with MS (or google) and then using a
  > potentially problematic web page to obtain a refresh-token. Once this is
  > done it is quite easy (in both gmail and outlook) to use the oauth2.el
  > library to authenticate.

Since I don't know anything about using MS mail, I can't tell from
those words whether you have described (1) something each user can do,
or (2) something that would have to be done once on behalf of GNUS.
Which one is it?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for explaining.  This looks generally siomilar to what Google
is doing with Gmail, but I can't tell whether they are the same.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Andrew Cohen]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> Since I don't know anything about using MS mail, I can't tell
    RS> from those words whether you have described (1) something each
    RS> user can do, or (2) something that would have to be done once on
    RS> behalf of GNUS.  Which one is it?

Sorry for not being clear. Others have described the issues with gmail
and I am saying that the issues are the same with outlook.

In trying to answer your question let me list the three steps I toke to
make this work with outlook:

1. REGISTRATION: An "app" needs to be registered with MS. Successful
    registration returns certain credentials. The returned credentials
    are what others have said google's terms of service forbid from
    being embedded in the app, although kmail and others do so anyway.

2. AUTHORIZATION: A user takes the credentials returned in step 1 and
    authorizes the "app" to access the user's outlook email. A "refresh
    token" is returned to the user.

3. ACCESS: Once authorized, the user can use the "refresh token" to
    retrieve an "access token" that is used like a temporary password to
    communicate with outlook over imap and smtp. The access token has a
    short lifetime (one hour) and new logins after that require
    repeating step 3 (using the same refresh token.)

Now to answer your question: the intent behind this process is that step
1 is performed once for the app (in our case gnus) and steps 2 and 3 are
performed by users. Step 2 is performed once by the user, and step 3 is
performed each time the user logs in. (Others have said that on occasion
authorization is revoked and step 2 must then be repeated, but I haven't
yet encountered this).

Nothing prevents each user from performing step 1 (that is, each user
registers their own app) but the process is technical and tedious, and
not something I think we can realistically expect from many users. It
also requires the use of a web browser and web pages that likely involve
javascript.

Step 2 is less tedious but also involves using a web browser and web
pages that use javascript (I am not 100% confident about the use of
javascript here, so it is possible that this part of the process could
be done in some other way).

Step 3 is the part that I referred to as easy---once the app has been
registered and the user has obtained the refresh-token, gnus can use the
oauth2 library on elpa to easily and directly manage the process of
obtaining the access-token and logging in.

Re: Making GNUS continue to work with Gmail

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If no one wants to do this for Gmail, I suppose no one will want to do
it for Microsoft either.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Making GNUS continue to work with Gmail

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

>>> "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Monday, 17 Aug 2020 at 17:02, Uwe Brauer wrote:
>> Users of academic institutions[1] found them self from one day to the
>> other, with their email accounts transferred to G-Suite (that this the
>> professional Gmail service), without doing anything at all.

> Or to Microsoft's office365 which is bad in similar ways as
> G-Suite.  And gnus, from what I hear, is going to have the same problem
> when they stop IMAP/POP access this autumn (northern hemisphere).

Not necessarily: I posed a message, in which google said it will drop it
plans to stop IMAP/SMTP access for G-Suite accounts, because of
Covid-19. I am not sure what's about the non G-suite accounts.


> I have no idea what solutions may exist or may be possible for
> Office365.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Making GNUS continue to work with Gmail

[Pankaj Jangid]

Uwe Brauer <oub@mat.ucm.es> writes:

> Not necessarily: I posed a message, in which google said it will drop it
> plans to stop IMAP/SMTP access for G-Suite accounts, because of
> Covid-19. I am not sure what's about the non G-suite accounts.
>

It is still working on G-suite accounts.