Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

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

[Bcc'd to Eduardo Chappa's address found on repo.or.cz/alpine.git]

Am 20.04.22 um 11:00 schrieb Andrew C Aitchison:
>
> On Wed, 13 Apr 2022, Matthias Andree wrote:
>
>> Am 12.04.22 um 23:18 schrieb Marco Gaiarin:
>> > I've followed literally:
>> >
>> > https://gitlab.com/fetchmail/fetchmail/-/blob/next/README.OAUTH2
>> >
>> > (eg, the readme of fetchmail 7) and works as expected. Now i have to
> manage
>> > some script to refresh the token, and download the email.
>> >
>> > I've only a question, before put all that stuff in 'production'.
>> >
>> > Juergen Edner say that the OAuth client created in 'Test mode' least
> at
>> > maximum a week.
>> > But if i try to publish the app, i need the Google approval process,
> because the api used (eg, GMAIL
>> > API) is 'restricted'.
>> >
>> > So, it is needed to publish the app? If yes, what is the shortest and
> error
>> > prone path to get it approved?
>> >
>> Their requiring registration of the "app" (we have never called
>> fetchmail that) - and not solely the user for his or her own account -
>> is one of the reasons why I say that OAUTH2 in this form is generally a
>> non-starter and does not scale.
>>
>> I cannot possibly register fetchmail with each and every mail service,
>> and device registration is somewhat pointless anyways.
>
> There has been some discussion of fetchmail and google in the email list
> for alpine - another open source MUA - particularly the thoughts
> of the main alpine developer at
> https://mailman12.u.washington.edu/pipermail/alpine-info/2022-April/001162.html


I have read Eduardo's mail again, and I come to different conclusions.

The thought of supporting users of accessing some service is nice, and I
have sympathy for it.

Also, sticking together as maintainers of Free and Open Source Software
and explaining the situation to users seems useful. So here is my take.


On a broader view, stepping back a yard from the drawing board:

The entire OAuth discussion so far has revolved around Google and
Microsoft wherever I have seen it (either by Andrew's pointer to ALPINE,
or on the getmail mailing list). The intro always goes as a variation on
the "$BIGCOMPANY wants OAuth to let me access my own data where IMAP or
POP3 used to work" theme. So why do YOU, the user, allow that to
happen?  Why do we foster monopolies?

Meaning we are not it is not technically about OAuth, but it is about
$BIGCOMPANY trying to own the game, your data, your
whatever_other_valuable by changing the rules. In essence, they try to
exert control over what applications the users are permitted to use to
access their VERY OWN PERSONAL data. Since when have we allowed such
intrusions into users' liberties to happen?

What do I have to gain as maintainer of a free and open source software
in that race? Nothing.

If I open the OAuth floodgate now, I pay with my time to implement,
debug, or - if contributed - review and integrate things. I will create
a technical debt for myself that there will be a permanent expectation
that this is supported, and that will also take time. All time that is
spent, or rather wasted, on trying to implement technical solutions for
a political problem. It could be invested in other changes that would be
useful to fetchmail. But look, if $BIGCOMPANY want to change rules again
tomorrow, they will do so. And fetchmail would be back to square one. A
spare-time open source maintainer cannot possibly win such a race. I
will not try.

We can stop that nonsense today, and not be made jump through the hoops.
The proper user response is: take your data while you still can, and to
where you will not be bullied. It may be inconvenient. I am not picking
up a technical fight to attack political arbitrariness. I am not going
to register fetchmail with any service provider. I have one voice, users
have many.

If someone has come to fetchmail for free beer, sorry, you've taken the
wrong turn. We want free choice in this place. This includes the choice
to leave fetchmail behind because I am not catering for that OAuth 2
need. But unlike $BIGCOMPANY, I need no high user count, I need not bind
your attention, I do not need you to stay on my site longer, because I
am not selling advertisements.

Fetchmail does not call home, it does not track you, it does not breach
your privacy, and everyone can see the source code and confirm that to
him- or herself. Try that with Outlook, or with the web-based interfaces
to GMail or Outlook.com/MSN.


What does this mean?

The existing prototypical code in the "next" branch (towards 7.0.0) can
remain until found vulnerable or nonfunctional. It will be considered
experimental unsupported code.

Feel free to discuss OAuth on the list, but make sure OAuth is in the
subject, and do not expect me to even pay attention.

If there is a service that offers OAuth 2.0 as part of a
non-discriminatory public mail service through IMAP and/or POP3 WITHOUT
requiring app registration, verification, and other nonsense, feel free
to tell me about it, we will need something to test against if it's not
M or G, and if it's not too much of an effort, we may actively implement
for that service to make a public demonstration that OAuth 2.0 can go
without exerting control over apps. That would be valuable in defanging
all the FUD and distractions around "less secure apps".

For OAuth pull requests, stick to contrib/ and make it standalone,
except for the minimal changes to the fetchmail code (which we already
have and might be sufficient already). Be sure to make contributions
high-quality, include documentation, be easily reviewed, and best two
other fetchmail users have tested the code on their systems, too, then I
may look at pull request. Make sure that you have all licenses to the
code you share, and the only acceptable languages for now are C, C++,
Python 3 (for upstream-supported versions) and portable Shell. Anything
else, ask me before you spend your time. About libraries, make sure they
blend in with existing licenses, in particular, they need to be
compatible with GPL v2, GPL v3, Apache, and OpenSSL licenses. Only use
widely-used high-quality libraries (Boost would be fine). I consider
dynamic linking to be creating derivative works, because the FSF (author
of the GPL) does.


Happy mail fetching,
Matthias