Re: [Fetchmail-users] Planned Google authentication changes

[Andrew C A. <fet...@ai...>]

On Fri, 4 Mar 2022, Matthias Andree wrote:

> Am 04.03.22 um 17:36 schrieb Andrew C Aitchison:
> > 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.

Thanks.
6.5 before 7 is sufficient.
I have gone to 6.5 for the logging timestamps; I was wondering if
I should copy Gentoo and go to 7 even though it is in alpha.

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

Sadly, I think *their systems* are more secure if they turn off IMAP/TLS
and rely on just one authentication system.
There may also be merit in device- and app-specific authentication tokens.

Plus TLS doesn't save passwords from the boot-strap problem. This
fancy new stuff may help to get a new password agreed between both ends 
securely.

Frankly, I am as worried about losing an account through a disk crash
as having it hacked. If I really care about the information being secure
I don't want it on the internet in the first place.

-- 
Andrew C. Aitchison                                     Kendal, UK
                         an...@ai...



On Fri, 4 Mar 2022, Matthias Andree wrote:

> 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.
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

-- 
Andrew C. Aitchison					Kendal, UK
 			an...@ai...