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)
