Hello Viktor.
SZÉPE Viktor wrote in <20191231181824.Horde.4Lg9jw_ypbkevrWkSPQQI2W@sze\
pe.net>:
|> I am sorry for all the obsoletion and backward-incompatibilities,
|> but we have to move forward and are getting bigger and bigger.
|
|+1
|
|I am also very happy that we will be OAuth-ing for Gmail.
I mean, they could have announced it several years in advance.
They likely use Linux all over the place, i seem to recall that
Rob Pike said (on some ML) he uses Ubuntu at his work place, and
there are other big player with long-term stability that extends
for five years or more, and which does not update software but for
bugfixes and security related patching, i think.
So basically Google not only hammered through OAuth before it
became an accessible standard, without giving good messages or
documentation. To me, connection was rejected and i think in
verbose mode i saw over the protocol that i should go to a web
site. So i then found myself on one of those was-this-helpful
websites which of course was not helpful, but through other MLs
i have read and especially the ArchLinux wiki entry for i think
mutt i finally got a clue and so we became a lesser secure app.
Doing this rant. We now support OAUTHBEARER/XOAUTH2, it will be
better and will have more glue when v14.10 comes. Resistance is
futile .. and i can store three tokens in a secure way locally.
I admit, i (will) store them all together with the regular GMail
password, but in a secure way.
S-nail will unfortunately cease to function for all Ubuntu and
Debian stable i think users who use GMail. Maybe i should have
added support for OAUTHBEARER/XOAUTH2 earlier, maybe Google should
have added SASL library support for their thing instead of
enforcing all software projects to add code especially for them.
And warn in advance. And i for one still fail to see why they do
not simply offer freely choosable passwords which offer reduced
access. Where is the difference to this fully blown OAuth thing?
Offer users a form where tokens get generated on button press, and
assign those to specific actions, GMail access, or SMTP access,
whatever? Then let users copy+paste these maybe short-lived
access tokens as passwords for their applications, and just offer
token refresh via a simple TLS secured connection handshake, via
the OAUTHBEARER/ XOAUTH2 "protocol". But anyway, not revealing
the actual account password but on their very website. Ach!
I will not implement full OAuth support, no. And trying to
fully implement OAUTHBEARER/XOAUTH2, i.e., managing the refresh
token update ourselves instead of relaying on some Google Python
script requires that we somehow have to deal with HTTP and JSON.
The former would not be that hard if only 1.0/1.1 is involved, but
HTTP/2 is a totally different thing. And adding a JSON parser is
not on the list of things i want to do in the forseeable future.
So this would involve more library bindings. cURL would be the
the likely choice for HTTP 1.0/1.1/2. The other one i do not know
yet. I tracked a few a few years back, but i have removed them
from my arena because no use case was in sight.
The thing is also. It is so complicated to setup OAUTHBEARER /
XOAUTH2 for GMail, that downloading the python script is not the
problem to think about. And python is there, on most systems. In
fact here i even have to have two versions. But i really would
like to get rid of that python script for S-nail, yes.
Ciao, and a happy new year 2020 i wish.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
