On Wed, Aug 05, 2020 at 11:19:53PM +0200, Michał Winiarski wrote:
Currently, this (or any other SASL oauth) plugin isn't available in any
of the upstream SASL implementations.
I also can't find any attempts to merge it upstream.
that's not a problem per se.
(it also isn't packaged by any of the distros that I'm using)
seems like at least arch and netbsd package cyrus-sasl-xoauth2.
someone seems to be building it for centos, too:
https://copr.fedorainfracloud.org/coprs/nurmukhamed/cyrus-sasl-xoauth2/
someone seems to have been successful using it with mbsync:
http://blog.onodera.asia/2020/06/how-to-use-google-g-suite-oauth2-with.html
I don't expect this to change anytime soon.
that's not a helpful attitude. make a solid howto for mbsync, so i can
include it (maybe on the website, or maybe in the docu directory, with a
mention in the manual under AuthMechs). then file bugs against the
mbsync packages of various distros, basically urging the mbsync
packagers to take the lead in having the plugin packaged.
to be clear, i really don't like the idea of including custom code that
is basically redundant with sasl. the first thing i did after adding
sasl support was to throw out the custom cram-md5 implementation.
i can add the patch on a branch for those interested, but that's about
it. at least until i see hard proof that the sasl route just isn't going
to work out despite someone seriously trying.
The reasoning behind this patch, is mainly due to SASL lagging behind.
have you tried figuring out why? oauth2 really isn't all that new at
this point, and it's not like there is too little demand.
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
