Cyrus SASL as alternative to GNU SASL

[josusky]

Hi,
I would like to know if it is OK to add Cyrus SASL library (https://www.cyrusimap.org/sasl/) as an alternative to GNU SASL. For obvious reason - I already have Cyrus SASL library as a dependency and would like to avoid having two libraries for the same thing.
There is also a precedent - SSL (crypto) functionality can be provided either by GnuTLS or by OpenSSL.
Any way, before I start doing extensive changes I wanted to ask. So if you are deadly against Cyrus SASL, please reject this issue.
JanO

[josusky]

Just to complete the picture. For quite some time I was fine without SASL support in vmime (using on the in-built "PLAIN" method as that is OK over TLS). However, I have stumbled upon "smtp.office365.com" that does not support AUTH PLAIN but the (outdated) LOGIN method. As the LOGIN mechanism is quite simple, the other option, that would work in my use case, would be to add into vmime this mechanism without need for an external library - i.e. to make it "in-built" like the PLAIN mechanism.

[vincent-richard]

Hello! It would be nice to offer an alternative to GNU SASL for VMime. On the other hand, LOGIN method is such simple that it could be indeed built-in.

By the way, I think it should be implemented directly as a subclass of builtinSASLMechanism, unlike AUTH PLAIN which is straight in the code and should be refactored...

[josusky]

Hi Vincent,
I agree that AUTH LOGIN is simple enough, I have been able to add it with about 30 lines of code in SMTPConnection::authenticate().
Having said that, I have also checked the possibility to use "builtinSASLMechanism" (and related classes) and it seems to me that most of the SASL related code is guarded by "#if VMIME_HAVE_SASL_SUPPORT" and/or with "#if GSASL_VERSION". The latter is clearly set in the "gnusasl.h" but, If I am not mistaken, the former is also set only if the GNU SASL library is available (detected by cmake). In other words, without external SASL library no SASL related code is being compiled - not even the virtual class/interface "SASLMechanism").
Thus, the refactoring would mean to make the basic SASL classes available unconditionally (i.e. removing most of the "#if VMIME_HAVE_SASL_SUPPORT" guards) and only guard the code specific for GNU SASL library itself - probably with the "#if GSASL_VERSION".
Is my observation correct?

[vincent-richard]

You are totally right! At least a simple subset of the SASL classes should be available even if VMIME_HAVE_SASL_SUPPORT is not enabled.