bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

Hi,

Some email services seem to be moving toward requiring MUAs to support
OAuth 2.0, one reason being that they would like MUAs to do two factor
authentication.  It would be nice to have this capability in Gnus's
nnimap.

The Gnus manual makes no mention of OAuth 2.0, I can't find any
suggested configurations online, and there's nothing mentioned in
debbugs about this.

Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
-- something that Gnus could eventually implement?  If so, I guess this
bug report could be where the idea is discussed.

Thanks,
Thomas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
> -- something that Gnus could eventually implement?  If so, I guess this
> bug report could be where the idea is discussed.

I don't think there's any way to ship Emacs with built-in oauth2 support
for doing auth with Gmail -- it requires distributions with API secrets
and stuff, and there's no secrets in the Emacs distribution.

Or is there a way to do that now?  I haven't been paying attention the
last few months.  I remember Thunderbird including some credentials in
the source code and saying, jokily, "remember, these are secret".
Somebody would have to register the Emacs "app" with Google, and for
Emacs, that would have to be the FSF, right?  And I don't see that
happening ever, ideologically.

But somebody could definitely write a package and put that on MELPA, and
do the registration, I think?  (With the same joke, of course.)

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Noam Postavsky]

On Tue, 19 May 2020 at 08:47, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> > Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
> > -- something that Gnus could eventually implement?  If so, I guess this
> > bug report could be where the idea is discussed.
>
> I don't think there's any way to ship Emacs with built-in oauth2 support
> for doing auth with Gmail -- it requires distributions with API secrets

There is something called xoauth2, is that related? Someone posted a
package for it, but the docs are a bit thin...

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> There is something called xoauth2, is that related? Someone posted a
> package for it, but the docs are a bit thin...
>
> https://github.com/ccrusius/auth-source-xoauth2

Below are the instructions for end-user usage.  I think you can sum that
up as "er, no".  :-/

   1. Go to the developer console,  
   https://console.developers.google.com/project  
   2. Create a new project (if necessary), and select it once created.  
   3. Select \"APIs & Services\" from the navigation menu.  
   4. Select \"Credentials\".  
   5. Create new credentials of type \"OAuth Client ID\".  
   6. Choose application type \"Other\".  
   7. Choose a name for the client.  
     
   This should get you all the values but for the refresh token. For that one:  
     
   1. Clone the https://github.com/google/gmail-oauth2-tools repository  
   2. Execute the following command in the cloned repository:  
     
   python2.7 python/oauth2.py  
   --generate_oauth2_token \  
   --client_id=<client id from previous steps> \  
   --client_secret=<client secret from previous steps>  
     
   You should now have all the required values (the :token-url value should  
   be \"https://accounts.google.com/o/oauth2/token\").")  


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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > There is something called xoauth2, is that related? Someone posted a
  > package for it, but the docs are a bit thin...

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

I read the response to your message, but I could not tell whether it
involves some nonfree software.  Does 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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
>> -- something that Gnus could eventually implement?  If so, I guess this
>> bug report could be where the idea is discussed.
>
> I don't think there's any way to ship Emacs with built-in oauth2 support
> for doing auth with Gmail -- it requires distributions with API secrets
> and stuff, and there's no secrets in the Emacs distribution.
>
> Or is there a way to do that now?  I haven't been paying attention the
> last few months.  I remember Thunderbird including some credentials in
> the source code and saying, jokily, "remember, these are secret".
> Somebody would have to register the Emacs "app" with Google, and for
> Emacs, that would have to be the FSF, right?  And I don't see that
> happening ever, ideologically.

I suppose it depends on what Google wants during the registration
process; I've never tried this registration process before so I don't
know what's involved.  Maybe someone from the FSF could research this?
Maybe a solution could be found for Free Software like Emacs.
Thunderbird is mentioned as a not-less-secure-app, so they seem to have
solved this problem to Thunderbird/Google's satisfaction.

According to communications I've received for my Google "G Suite" email
service, Google plans to change these "less secure app" policies such
that next year they won't allow Gnus to connect using username/password
authentication like it does today.

> But somebody could definitely write a package and put that on MELPA, and
> do the registration, I think?  (With the same joke, of course.)

OK, maybe Google could relax the secrecy requirement for Emacs though,
since I'd hope they'd be sufficiently Free-Software-friendly to work
something out.  I assume, given what Thunderbird is doing, that the
secrecy requirement isn't something fundamental to OAuth 2.0's security.

Thomas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[David Engster]

> Maybe a solution could be found for Free Software like Emacs.
> Thunderbird is mentioned as a not-less-secure-app, so they seem to have
> solved this problem to Thunderbird/Google's satisfaction.

No, they haven't. It's just that at the moment, no one cares.

It is pretty obvious that OAuth2 client id/secrets do not make sense in
desktop applications (whether (F)OSS or not), making their whole point
moot. Google admits this much in their documentation, where they say

  The process results in a client ID and, in some cases, a client secret,
  which you embed in the source code of your application. (In this
  context, the client secret is obviously not treated as a secret.)

(see https://developers.google.com/identity/protocols/oauth2)

People took this paragraph as permission to simply put client id and
secret directly into the source code. However, Google *explicitly*
forbids this in their developer TOS:

  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.

(see https://developers.google.com/terms)

The Thunderbird people simply ignore this and do it anyway, but it's not
like they have much choice.

> OK, maybe Google could relax the secrecy requirement for Emacs though,
> since I'd hope they'd be sufficiently Free-Software-friendly to work
> something out.

Google does not care one bit.

The solution to this problem is to choose another mail provider.

-David

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> I suppose it depends on what Google wants during the registration
> process; I've never tried this registration process before so I don't
> know what's involved.

You register a developer account (with your name and address and stuff),
and you then register an application.  Everybody connecting to Gmail
will use this application ID, so you are "responsible" in some degree
for the users of your application.  Rate-limiting, for instance, are
based on the application ID.

> OK, maybe Google could relax the secrecy requirement for Emacs though,
> since I'd hope they'd be sufficiently Free-Software-friendly to work
> something out.  I assume, given what Thunderbird is doing, that the
> secrecy requirement isn't something fundamental to OAuth 2.0's security.

It is.  OAuth login without secrets isn't any more secure than normal
user name/password logins, so making apps run through these hoops is
just obfuscation.  It's obvious what Google's end game here is: They
will stop IMAP access altogether to Gmail as soon as they are able to
without losing too many of the users.

This OAuth 2.0 stuff is just a sop they can point people towards while
they're closing off access to their walled garden: "See!  We're still
open!"  And people bite.  Some hackernews commented something like "I
don't see why people are complaining...  they just have to run a
script..."

The only solution here is to leave Gmail.

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

This is alarming news.  If these reports are correct, they mean that
Google will entirely cut off access to Gmail from the Free World.

Can you find a web page that describes the danger in a clear way,
with references to substantiate the warning?  That is the first thing
we need in order to campaign to convince Google not to do 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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Stefan Kangas]

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. ]]]
>
> This is alarming news.  If these reports are correct, they mean that
> Google will entirely cut off access to Gmail from the Free World.
>
> Can you find a web page that describes the danger in a clear way,
> with references to substantiate the warning?  That is the first thing
> we need in order to campaign to convince Google not to do it.

Here are two relevant announcements, I think:

Turning off less secure app access to G Suite accounts
https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html

Less secure app turn-off suspended until further notice
https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html

In the second of them, we read:

    Last December, we announced that we’d be turning off less secure app
    (LSA) access to G Suite accounts, and that you should migrate to OAuth
    authentication instead. The first phase of the LSA turn-down was
    scheduled for June 15, 2020. As many organizations deal with the impact
    of COVID-19 and are now focused on supporting a remote workforce, we
    want to minimize potential disruptions for customers unable to complete
    migrations in this timeframe.

    As a result, we are suspending the LSA turn-off until further
    notice. All previously announced timeframes no longer apply.

So I guess this means that in the mid-term, people should seriously
consider leaving Google.

Hope that helps.

Best regards,
Stefan Kangas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

Hi Stefan,

Stefan Kangas <stefan@marxist.se> 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. ]]]
>>
>> This is alarming news.  If these reports are correct, they mean that
>> Google will entirely cut off access to Gmail from the Free World.
>>
>> Can you find a web page that describes the danger in a clear way,
>> with references to substantiate the warning?  That is the first thing
>> we need in order to campaign to convince Google not to do it.
>
> Here are two relevant announcements, I think:
>
> Turning off less secure app access to G Suite accounts
> https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
> 
> Less secure app turn-off suspended until further notice
> https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html
>
> [...]

Yes, those are the relevant announcements, thanks.

Quoting from the first announcement:

"If you are using Thunderbird or another email client, re-add your
Google Account and configure it to use IMAP with OAuth."

It seems like Google is acknowledging Thunderbird as a valid option
post-"less-secure-app" turn-off there.

Richard, I think Lars's and David's summary of Thunderbird's situation
highlights the non-technical issues blocking GNU Emacs from supporting
OAuth 2.0 access to the G Suite IMAP service.  I'm wondering if the FSF
could help with those issues.

> So I guess this means that in the mid-term, people should seriously
> consider leaving Google.

Agreed, and I am [1], but maybe a better outcome could be reached.  It
sounds like from Thunderbird's situation, changes to Google's developer
terms of service, giving some consideration to Free Software projects
using these APIs, could solve the problem.

It might take non-technical discussions between the FSF and Google, but
that's one of the FSF's functions, AIUI.  Maybe the result could be a
model for how to handle other similar situations, since Emacs needing
"API keys" to access network services is not unique to G Suite or
Google.

Thomas

1. I'm tempted to try Lars's self-hosted email script. ;-)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 seems to me that the requirement for a secret key in a user program
is fundamentally incompatible with free software.  A free system
cannot keep secrets from the user.  However, if Google is willing to leave a space to use free clients, something could be worked out.

First I have to finish studying all this.  I will send mail now to fetch
those articles.

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> It seems to me that the requirement for a secret key in a user program
> is fundamentally incompatible with free software.  A free system
> cannot keep secrets from the user.  However, if Google is willing to
> leave a space to use free clients, something could be worked out.

At present, there doesn't seem to be any way to follow Google's explicit
instructions as to how OAuth 2.0 support should be done in free
software -- even if they tacitly are saying through unofficial channels
"but we don't really mean it" by saying that Thunderbird is still
working.

So I'm closing this bug report, as this isn't something that can be
fixed here, but it something the FSF will have to negotiate with Google.

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > So I'm closing this bug report, as this isn't something that can be
  > fixed here, but it something the FSF will have to negotiate with Google.

I guess so -- if we can find someone there to talk with.  Can someone
find out whether Google still has a representative concerned with
"open source"?

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Simon Leinen]

> I guess so -- if we can find someone there to talk with.  Can
> someone find out whether Google still has a representative concerned
> with "open source"?

I'd try Chris DiBona <cdibona@google.com>
-- 
Simon.

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > Chris DiBona <cdibona@google.com>

He was Google's "open source" person.  Do you know whether he still is?

I got an answer from a KDE developer, and with luck that should
be enough.  If it isn't, we can try DiBona.

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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Simon Leinen]

>> Chris DiBona <cdibona@google.com>

> He was Google's "open source" person.  Do you know whether he still is?

His LinkedIn profile and Wikipedia page still list him as Director of
Open Source at Google.

Several years ago I talked with him about license options (specifically
GPL variants) on Google's now-defunct source-code hosting service, and
found him knowledgeable and willing to help.

> I got an answer from a KDE developer, and with luck that should
> be enough.  If it isn't, we can try DiBona.

Sounds good!

All the best,
-- 
Simon.

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 don't think there's any way to ship Emacs with built-in oauth2 support
  > for doing auth with Gmail -- it requires distributions with API secrets
  > and stuff, and there's no secrets in the Emacs distribution.

There are no real secrets in any free operating system.  The only way
I know of to have a key and effectively keep it secret with software
is to bury it in a nonfree excutable, and that is not a solution; it
only replaces one impassable obstacle with another impassable
obstacle.

  > Or is there a way to do that now?  I haven't been paying attention the
  > last few months.  I remember Thunderbird including some credentials in
  > the source code and saying, jokily, "remember, these are secret".
  > Somebody would have to register the Emacs "app" with Google, and for
  > Emacs, that would have to be the FSF, right?  And I don't see that
  > happening ever, ideologically.

If what Thunderbird is doing does not involve nonfree software,
I see no reason we couldn't do the same.

But I doubt that Google will continue accepting this forever.  Google
might eventually decide to kick off Thunderbird users, and Gnus users
along with them.

  > But somebody could definitely write a package and put that on MELPA, and
  > do the registration, I think?  (With the same joke, of course.)

To the extent that this approach is usable, we woultn't need to
relegate it to MELPA.  We could put it straight into Gnus.

The two Google announcements clearly describe how Google plans to
block access with anything other than OAuth 2.  They don't go into
much detail about what OAuth 2 requires, and don't describe how this
conflicts with free software.

Can someone find a page describing this issue in a careful
and thorough way, written by someone who knows the subject?

Can someone get in touch with a Thunderbird developer or expert
who would like to discuss the issue?

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[David Engster]

> The two Google announcements clearly describe how Google plans to
> block access with anything other than OAuth 2.  They don't go into
> much detail about what OAuth 2 requires, and don't describe how this
> conflicts with free software.
>
> Can someone find a page describing this issue in a careful
> and thorough way, written by someone who knows the subject?

I've described the main issue in another mail in this bug thread. The
problem is that Google's terms of service explicitly forbid to put
client IDs into "open source projects". You can read their terms of
service here:

  https://developers.google.com/terms

Section 4b, paragraph 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.

So for authors of (F)OSS non-web applications, this in effect makes it
impossible to use OAuth2 with Google services if a client id/secret is
required. The client id/secret is used to identify the application that
is making the request.

-David

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > Some email services seem to be moving toward requiring MUAs to support
  > OAuth 2.0, one reason being that they would like MUAs to do two factor
  > authentication.  It would be nice to have this capability in Gnus's
  > nnimap.

This may raise some moral issues -- depending on what practical
requirements there are.  Would you like to explain to me how the
two-factor authentication works in practice, and what the user needs
to have?

For instance, can the user do this using nothing but Emacs running on
some operating system (GNU/Linux, we hope)?  If not, what else does
the user need to have?

Does it require the user to have a portable phone?

Do those email services plan to require two-factor authentication
or offer it as an option for the user?

Are there free implementations of OAuth 2.0?  What are their licenses?

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

Hi Richard,

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. ]]]
>
>   > Some email services seem to be moving toward requiring MUAs to support
>   > OAuth 2.0, one reason being that they would like MUAs to do two factor
>   > authentication.  It would be nice to have this capability in Gnus's
>   > nnimap.
>
> This may raise some moral issues -- depending on what practical
> requirements there are.  Would you like to explain to me how the
> two-factor authentication works in practice, and what the user needs
> to have?

Thanks for having a look at this bug report.

I could explain in a general way how this might work for Gnus's nnimap
backend.  However, given what I've learned from Lars's and David's
responses, I would prefer to keep this bug report solely about OAuth 2.0
support, with a focus on Google's email services.

Two factor authentication can be implemented by a service without
requiring OAuth 2.0, and vice versa.  (Given what I've learned from Lars
and David I probably should not have even mentioned it in the initial
report.)  Therefore I think lumping the two concepts together in this
bug report will be too confusing.

We could open a new bug report, or open a discussion on emacs-devel,
about two factor authentication support in Emacs generally.  However, I
don't have a specific example to discuss or a bug to report about a
specific service, so I don't think the resulting discussion would be
focused enough to be productive.

Thomas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > Two factor authentication can be implemented by a service without
  > requiring OAuth 2.0, and vice versa.

Ok.  But my concern is not about OAuth in particular.  The crucial
question is, will Gmail in the future permit access from the Free World
in any manner whatsoever?

In other words, if we look at all the ways of logging in that Gmail
permits in the future, will _any_ of them be usable in the Free World?

Can you help me find the answer?  If it is no, we had better put all our
strength into changing that answer.



-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

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. ]]]
>
>   > Two factor authentication can be implemented by a service without
>   > requiring OAuth 2.0, and vice versa.
>
> Ok.  But my concern is not about OAuth in particular.  The crucial
> question is, will Gmail in the future permit access from the Free World
> in any manner whatsoever?
>
> In other words, if we look at all the ways of logging in that Gmail
> permits in the future, will _any_ of them be usable in the Free World?
>
> Can you help me find the answer?  If it is no, we had better put all our
> strength into changing that answer.

OK, I'll try to help, but I don't know what Google or Gmail will do in
the future, in general, obviously.  I wanted this bug report to be
specifically about Gnus, IMAP and OAuth 2.0 (which the responding
experts correctly inferred was more precisely about Gnus, IMAP and
Gmail's proposed OAuth 2.0 policy change).

Your question reminded me that Gmail provides "basic HTML view" which
does not require any Javascript whatsoever for sign-in or for the main
interface, and thus is fully useable with Emacs Web Wowser (eww).  For
me that isn't a viable alternative to Gnus, so it's tangential to this
bug report, but that access method is feasible using entirely Free
Software.  Hopefully that answers your question.

Will "basic HTML view" still be available after Gmail starts mandating
OAuth 2.0 for IMAP access (assuming they do, sometime in the future)?  I
suspect it will, but I don't know.

Thomas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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'll try to help, but I don't know what Google or Gmail will do in
  > the future, in general, obviously.

I don't expect you to practice precognition.  But it may be possible
to deduce something by putting their announcements together with other
known facts.  Maybe we could figure out questions to ask them.

  > Your question reminded me that Gmail provides "basic HTML view" which
  > does not require any Javascript whatsoever for sign-in or for the main
  > interface, and thus is fully useable with Emacs Web Wowser (eww).

That is a significant fact.  It means that using Gmail in the free
world won't become entirely impossible.  Thanks.
 
So I modify the question:

   Will Gmail in the future permit access from the Free World
   to read mail with a free local MUA in any manner whatsoever?
   
And there is another followup question:

Is it possible to log in on basic HTML view
passing via a proxy that will hide your actual location?
It is possible that basic HTML view won't allow this.

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

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. ]]]
>
>   > OK, I'll try to help, but I don't know what Google or Gmail will do in
>   > the future, in general, obviously.
>
> I don't expect you to practice precognition.  But it may be possible
> to deduce something by putting their announcements together with other
> known facts.  Maybe we could figure out questions to ask them.
>
>   > Your question reminded me that Gmail provides "basic HTML view" which
>   > does not require any Javascript whatsoever for sign-in or for the main
>   > interface, and thus is fully useable with Emacs Web Wowser (eww).
>
> That is a significant fact.  It means that using Gmail in the free
> world won't become entirely impossible.  Thanks.
>  
> So I modify the question:
>
>    Will Gmail in the future permit access from the Free World
>    to read mail with a free local MUA in any manner whatsoever?
>    
> And there is another followup question:
>
> Is it possible to log in on basic HTML view
> passing via a proxy that will hide your actual location?

Yes.  Here is the recipe I tested:

   sudo apt install proxychains
   sudo sed 's/#quiet_mode/quiet_mode/' -i /etc/proxychains.conf
   ssh -ND 9050 <host-from-which-to-access-mail> &
   HOME=$(mktemp -d) proxychains emacs -Q -nw
   M-x eww RET https://gmail.com RET
   [Use the usual web-based log-in procedure via Emacs Web Wowser.]

The log-in procedure was successful and I was able to use the basic HTML
view interface.

To confirm the results of the test, I also logged into the same service
via Firefox and a direct connection.  After I did the procedure above,
the Firefox session showed:

"This account is currently being used in 1 other location (<address>)."

Where <address> was the IP address of <host-from-which-to-access-mail>.

The above is just an example, other methods may be superior in various
ways, but I think this proves that Gmail is useable in Emacs Web Wowser
via a proxy.

Thomas

P.S. Prior to installing proxychains, I tried using Emacs's built-in
proxy support in the same way.  There are references to SOCKS in the URL
manual, but I couldn't find an easy way to make EWW use localhost:9050
as a SOCKS proxy.  I debugged until I got to the comment "Should check
for socks" in url-default-find-proxy-for-url.

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

  > > Is it possible to log in on basic HTML view
  > > passing via a proxy that will hide your actual location?

  > Yes.  Here is the recipe I tested:

That is a little less bad.

Is there any positive indication that Google will let people continue
using this basic HTML mode?

I wonder -- is it possible for a program talking to that proxy to
convert the messages in the Gmail server into a mailbox file which you
could then pass to an MUA?


-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Thomas Fitzsimmons]

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. ]]]
>
>   > > Is it possible to log in on basic HTML view
>   > > passing via a proxy that will hide your actual location?
>
>   > Yes.  Here is the recipe I tested:
>
> That is a little less bad.
>
> Is there any positive indication that Google will let people continue
> using this basic HTML mode?

It seems like basic HTML view is the old mode that is still being
maintained.  Just after logging in, an HTML page mentions that "standard
view" requires JavaScript and that to use standard view one must enable
JavaScript.  But the same page then provides the option, "To use [...]
basic HTML view, which does not require JavaScript, click here.".  After
logging in, one can set basic HTML as the default view.  So it seems
like it is still fully supported.

(As an aside: basic HTML view uses old HTML-table-based, rather than new
CSS-based, layout, so it lays out nicely in EWW; in other words, it
provides a user interface that is friendly to simple browsers.  It's by
no means an efficient alternative to Emacs's native MUAs though.)

> I wonder -- is it possible for a program talking to that proxy to
> convert the messages in the Gmail server into a mailbox file which you
> could then pass to an MUA?

I don't see a way of downloading mailbox files via simple links.

It is technically possible to implement the conversion you're
describing, since one can click through several links for a given
message and eventually get the original text.  However, it would be an
awkward, fragile HTML-scraping-type implementation that I don't expect
would be viable in practice.

Thomas

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 wonder -- is it possible for a program talking to that proxy to
  > > convert the messages in the Gmail server into a mailbox file which you
  > > could then pass to an MUA?

  > I don't see a way of downloading mailbox files via simple links.

I don't see how "simple links" relates to what I had in mind, so I have
a feeling this is a misunderstanding.

  > It is technically possible to implement the conversion you're
  > describing, since one can click through several links for a given
  > message and eventually get the original text.  However, it would be an
  > awkward, fragile HTML-scraping-type implementation that I don't expect
  > would be viable in practice.

That is what I had in mind.  Is it "fragile"?  If Google changes the
UI of the basic HTML mode, it would break.  Does Google change that
very often?

In any case, if Google breaks all advertized other ways of
transferring a Gmail account's incoming mail into a free MUA, scraping
would be MUCH better than no way at all.


-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 got this information from someone who knows
who says it is all from published information.

Does this enable us to cope with Google's planned changes?

======================================================================
GNUS could follow the same process of the the maintainers of KMail to 
get approved:

 
https://www.reddit.com/r/kde/comments/gi5bol/kmailkontact_oauth_signin_with_gmail_enabled_again/

This had nothing to do with shutting off access to free MUAs. It's a 
matter of hardening the security of GMail accounts and having all 
3rd-party clients (free and non-free alike) publish a privacy policy 
where they describe their usage of the GMail APIs, as described in this 
thread:

https://www.reddit.com/r/kde/comments/cj7t7c/kmail_doesnt_let_me_sign_in_with_gmail/evchyih/

In particular:

   Google is not concerned with the legal "significance", they just care
   about the part about what features of their API we use and how, which
   seems to be incomplete, judging from the last email I got from them
   just yesterday, which is my responsibility to update, as I'm more or
   less the Google integration maintainer in PIM, since I wrote most of
   the stuff (silly me!) :D

The implementation details for XOAUTH2 are here, along with sample code 
and links to the relevant RFCs:

   https://developers.google.com/gmail/imap/xoauth2-protocol
-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I got this information from someone who knows
> who says it is all from published information.
>
> Does this enable us to cope with Google's planned changes?
>
> ======================================================================
> GNUS could follow the same process of the the maintainers of KMail to 
> get approved:
>
> https://www.reddit.com/r/kde/comments/gi5bol/kmailkontact_oauth_signin_with_gmail_enabled_again/

The link doesn't same what the process is, so I don't know whether it
enables us or not.  In particular, it doesn't say anything about how the
free software application is supposed to keep the secret keys secret,
which is (of course) totally impossible for an application like Emacs.

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 link doesn't same what the process is, so I don't know whether it
  > enables us or not.  In particular, it doesn't say anything about how the
  > free software application is supposed to keep the secret keys secret,
  > which is (of course) totally impossible for an application like Emacs.

Can you try contacting and asking the developers of Kmail about any points
that are not clearly stated in what I sent you?

-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > The link doesn't same what the process is, so I don't know whether it
>   > enables us or not.  In particular, it doesn't say anything about how the
>   > free software application is supposed to keep the secret keys secret,
>   > which is (of course) totally impossible for an application like Emacs.
>
> Can you try contacting and asking the developers of Kmail about any points
> that are not clearly stated in what I sent you?

If the Emacs maintainers wants to get involved with Google on this,
that's fine by me.  My stance is that Google is obviously not doing
these changes on a good-faith basis, but as a long-term way to shut off
all avenues of using Gmail without going through the official interface.

So I'm not interested in spending any time on this.

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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 the Emacs maintainers wants to get involved with Google on this,
  > that's fine by me.

Do you mean, that Eli or Stefan should address this problem in Gnus?
I don't think we can possibly do anything on this.

  >   My stance is that Google is obviously not doing
  > these changes on a good-faith basis, but as a long-term way to shut off
  > all avenues of using Gmail without going through the official interface.

That doesn't seem to be what the Kmail developers think.

Many Gnus users will be unhappy if it stops working with Gmail.


-- 
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)

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > If the Emacs maintainers wants to get involved with Google on this,
>   > that's fine by me.
>
> Do you mean, that Eli or Stefan should address this problem in Gnus?
> I don't think we can possibly do anything on this.

No, I don't expect them to implement this.  But somebody has to open a
developer account at Google and register the Emacs "application", and
that has to be the FSF.  They will then be able to generate the API
secret key that will then be included, non-secretly, specifically
countering the contract you enter into with Google, when you then
publish it openly in the Emacs sources.

>   >   My stance is that Google is obviously not doing
>   > these changes on a good-faith basis, but as a long-term way to shut off
>   > all avenues of using Gmail without going through the official interface.
>
> That doesn't seem to be what the Kmail developers think.
>
> Many Gnus users will be unhappy if it stops working with Gmail.

Definitely.  But it's not something I can help with.  Blame Google.

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[황병희]

>> Many Gnus users will be unhappy if it stops working with Gmail.
>
> Definitely.  But it's not something I can help with.  Blame Google.

I just myself mark as IMPORTANT this PR because i use Gmail + Google Apps.

Sincerely,

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[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. ]]]

Can someone please make contact with the Kmail developers so I
can ask them for advice?

-- 
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)

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

[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

[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

[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

[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

[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

[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

[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

[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

[황병희]

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

[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

[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

[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

[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

[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 <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

[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

[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

[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

[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

[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

[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

[황병희]

> 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

[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]

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

[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

[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

[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

[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

[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. ]]]

  > 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: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: 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: 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 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

[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

[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

[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: 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: 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

[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

[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

[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: 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. ]]]

  >   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

[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

[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

[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: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

[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

[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

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

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

[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

[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

[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

[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

[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 --]

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I know this bug is marked as wontfix however more and more providers are
moving to Oauth2, even those that use plain standards like
imap/{cal,card}dav/smpt, thous increasing the importance of Oauth2
support in Gnus.

The main advantage I see is that oauth allows for two factor
authentication and the invalidation of the "password" that the app
stores. The password or token that the app has usually only lasts for a
duration of time and can be invalidated if needed. Like if the person no
loner works for the employer or the device has been stolen.

Some providers like Microsoft require it next year and the employer
can already enforce the use of Oauth2 [1].
The argument "just use another email provider" doesn't really work in
such cases.

SailfishOS recently addeded oauth2 support for Microsoft Oauth and
KDE also does support it[2].
In the case of Microsoft there are no "secrets" that can be stored publicly just the
application id[3].

Without proper OAuth2 support there is no use for Gnus for such users,
except to try third party solutions that can help.

On Elpa there's oauth2.el which provides Oauth2 support for Emacs. There
are externals who implemented oauth for Gmail[4] and Microsoft 365[5]
through the use of oauth2.el.

However these don't handle the oauth workflow of acquiring the token.
It is possible to try to do that inside emacs or use an external browser
and then catch the response or make the user copy the response address
into Emacs.

The main issue to implement this I think is to have an official "appid"
for Emacs and add the Oauth2 workflow.
I don't know about google right now but for Microsoft 365 this seams
feasible as there's just an appid that can be stored publicly. 


Br,

Björn Bidar

---

[1] https://techcommunity.microsoft.com/t5/exchange-team-blog/improving-security-together/ba-p/805892
[2] https://invent.kde.org/pim/kdepim-runtime/-/tree/master/resources/ews/ewsclient/auth
[3] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
[4] https://github.com/ggervasio/gnus-gmail-oauth/
[5] https://gitlab.com/Binary-Eater/gnus-o365-oauth2/-/tree/master

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

[Deus Max]

On Sat, Oct 29 2022, Björn Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> I know this bug is marked as wontfix however more and more providers are
> moving to Oauth2, even those that use plain standards like
> imap/{cal,card}dav/smpt, thous increasing the importance of Oauth2
> support in Gnus.
>
Ditto. OAuth2 authentication is now needed, not just nice to have.
Please re-open ticket.
   
> Some providers like Microsoft require it next year and the employer
> can already enforce the use of Oauth2 [1].
> The argument "just use another email provider" doesn't really work in
> such cases.

Microsoft disabled Basic Authentication for POP, IMAP and other
protocols on Oct. 01, 2022. As you may know, a lot of work places use
office365.
https://answers.microsoft.com/en-us/outlook_com/forum/all/imap-password-not-working/d4432df0-f7ea-42b7-90e7-2cf1e0e02e4a

My understanding from reading M$ documentation is that now OAuth2 is the
only method for a client to connect to office365 IMAP. Correct me please
if I'm wrong.

>
> Without proper OAuth2 support there is no use for Gnus for such users,
> except to try third party solutions that can help.
>

Sadly true.