Re: [Fetchmail-users] Planned Google authentication changes

[Matthias A. <mat...@gm...>]

Am 04.03.22 um 17:36 schrieb Andrew C Aitchison:
> On Fri, 4 Mar 2022, joe a wrote:
>
>> Received the email below from Google (links deleted).   What does
>> this mean for Fetchmail?  A quick search turned up "not much".
>
> Fetchmail 7, which is still in alpha (but, I believe, distributed with
> Gentoo Linux) has OAuth 2.0 support built in.
>
> Fetchmail 6 has third party patches which add (X)OAuth 2.0 support
>   http://mmogilvi.users.sourceforge.net/software/oauthbearer.html
> - patches for the latest releases are also available on my website:
>   https://www.aitchison.me.uk/fetchmail/
> (I am about to improve the landing page).
>
> With fetchmail 7 in alpha and fetchmail 6.5 in beta,
> it would be useful to see a roadmap of future fetchmail development.

There is no such thing as a roadmap if you are looking for planned
release dates.
This is currently a volunteer spare-time project, not a
commercially-organized one, and apparently some big tech are trying to
squeeze out the small ones. More below.

Fetchmail 6.5 should arrive on a scope of months though, albeit without
OAuth2. It will cut off support for systems not compliant to C99 and/or
the Single Unix Specification v3.

For fetchmail 7 the release date "depends" on circumstances I have not
planned yet. After 6.5.


I am quite unhappy to put it politely that the Big Tech badmouth (not to
say libel) apps using established password logins through TLS and that
offer TLS certificates and others means as "less secure apps". What do
they think they are doing with asking browser-like client feature sets
to obtaining a ticket for logging into another system? How many security
fixes are needed in browsers for each and every release again, to be
sure nobody steals that token through some phishing or cracking?

How many hoops do open source application users or maintainers need to
jump through to possibly or then again not register their app for OAuth?
And then again for the next service? What are the policies, check
Android's FairEmail.
https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq147
-- It's not a hard obstacle, but still the process would be at Google or
some other Big Tech's discretion and however else believes they need to
exert control over what client is permitted to get OAuth for their
flavor of the service as well.

How many services would I, or we counting users in, have to register
fetchmail with? This just does not scale to do centrally. As maintainer,
you cannot guarantee a quality of service if aiming at a moving target.

Next day they change their login or come up with another revision of the
hundreds-of-pages OAuth2 framework and implementation sepcifications
scattered thorugh many IETF docs, or change whatever detail they forgot
to document but that Thunderbird just did ever so slightly differently
that it did not trip up their tester. And this is just for
authentication. How crazy is that.


Please, someone using fetchmail with Google or Microsoft or other
services that want to shove OAuth down your throats, please volunteer to
search the documentation for your service and see if it is possible to
set *app-specific passwords* instead.

Once upon a time, this used to work for some service I did use at that
time.
The Big Techs will likely run stats to see when is a safe time to flip
switches (and which ones) in order not to drive too many users away.

> IIRC I had to enable "use less secure" in gmail for it to work with
> fetchmail.  Perhaps  I was just in a hurry then and lazy now?
>
Yes, that switch used to be there. Not sure how long it will last.

Or just go find a service that does not scan all your email and forces
YOU to change.


> X(O)Auth 2.0 authentication *is* more complex than traditional methods
> and documentation could be better.

And that is the crucial point. If you want a security sensitive
component designed securely, you don't overengineer it with a dozen of
specs dozens of pages each, but something simple, reproducible,
auditable that is self-contained in one central spec, possibly relying
on another set of well-established building blocks for elementary
functions such as crypto. And then you don't offer half of the
interfaces you've documented. If you fail to document that properly,
that entire cardhouse will collapse.