(bug to BCC, let's really not keep the discussion there) On Fri, Jun 28, 2019 at 5:28 PM Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
> |I didn't treat you as such; but, if XOAUTH2 was a supported SASL > > But Google does! Google does. > It's not far off. If I can, I avoid giving software privileges it doesn't need. I think s-nail is simple enough and would not call it really insecure. But, if it can function without knowing a password that grants software access to everything in my Google account, why not? (Same applies to other accounts; why would a hypothetical deployment of Dovecot accept the same authorization token -- password or otherwise -- that grants me access to code review tool Gerrit?) > > As above, Ivan. The problem is solely on code level, and with > filter i mean that we could implement a SASL layer which is > temporarily installed as an event handler onto the socket's I/O while > the SASL session is active. This is identical in between all > protocols (iirc), and this that single "filter" would be generic > and could be shared. > SASL mechanisms are identical; how the SASL bytes are encapsulated is very much protocol specific. XMPP encapsulation is nowhere near similar to IMAP's, SMTP's or IRC's. > > |Using libsasl2 for this, well, that's the interesting part. You get > |pluggability, you get a lot of SASL mechanisms already implemented for > |you, and users can write their own plugins as well. > > Oh! You want SASL support???? Now i got ya!! > > Oh, i'll tell you what i do. I delay the release of v14.9.14 by > one week, and promise i will use the time to look into SASL and > try to hack (and it will be exactly that) it in, ok? I do not > promise i will make it, if it will be so dirty that i am going > nuts over it i will stop the effort. But i promise i will put > some good will into it. All right? Ivan? > I do hope you did not perceive anything I wrote as a demand -- I do *not* make demands of free software developers, merely share information in case they can make some time for things that might be useful to me. In case of libsasl2, its pluggability and widespread availability means you might actually be able to simplify some s-nail code and not depend on GSSAPI *directly*. (I didn't look at it yet.) I will certainly keep using s-nail for my local mail as-is; there is *zero* rush to have libsasl2 as the backend to implement SASL negotiation! I am appreciative of it as-it-is. If you do feel like it's an interesting thing to explore, I certainly wouldn't mind it. But please, only look at adding this if you feel like it. s-nail existing, being maintained, using GSSAPI and offering IMAP support (insanely cool!) is already very much appreciated. Vielen Dank für Ihre Arbeit, Steffen!
