Folks,
A first cut at GNU SASL (gsasl) integration has been written for Exim.
At this time, it's server-only. I'm not sure whether or not to
integrate this for release as part of the next Exim. Feedback may make
the difference, but something more informative than "+1"/"me too"
please.
This authentication driver can be built into Exim at the same time as
Cyrus SASL. It provides the mechanism work, but does not provide
authentication sources (an inherent difference between the two
libraries). You'll need to use server_condition or server_password for
that, depending upon the mechanism used.
The code is on the gsasl branch of git:
http://git.exim.org/exim.git/shortlog/refs/heads/gsasl
and includes full documentation.
I've built the PDF and made it available at:
http://www.exim.org/~pdp/spec-gsasl-dev.pdf
Note that this claims to be for 4.77. The major changes are to chapter
33 and the insertion of a new chapter 38.
There are a number of open issues:
(1) Versioning of available features and library interfaces is not
ideal. I wrote and tested against gsasl 1.6.1.
(2) Some aspects of the API do not let Exim generically support future
mechanisms; instead, knowledge of each mechanism needs to be
embedded into Exim. This is why the versioning is not ideal. It's
not immediately obvious which versions of gsasl introduced which
mechanism identifiers. Code archaeology would answer that, but I'm
currently adopting the approach of "report compile problems you
encounter, I'll then see what needs to be done".
I'm a reluctant to commit the Exim Maintainers to ongoing
integration work which will either tie particular releases of Exim
to particular releases of gsasl, or require an increasing amount of
spaghetti inside Exim to sometimes use some new symbols and some
logic for when to set $auth1, to which gsasl property, and with
what prior dependencies.
I'd be happier if I'd received a response to my mail to the gsasl
mailing-list, to discuss the issues and if I saw gsasl moving in a
direction which would make it easier for us in the future. But it
might just be that the goals and aims of the two projects are not
mutually compatible and we'll just not integrate this work for
release as part of Exim.
(nb: it's only been a little over a week since I mailed them, so
this may be the same issue Exim sometimes has, as a result of
relying solely upon volunteers for doing the work).
(3) Released versions of OpenSSL do not, that I have seen, provide an
API for cleanly extracting channel binding information, so that
code can only be used with GnuTLS. I do not use GnuTLS, so that
code is currently untested. (See the docs for information on
channel binding).
(4) I haven't used the SCRAM mechanisms and suspect that we might want
to make $auth1 available at time of expanding the scram options, or
make the results of those two options available as variables while
expanding server_password. Informed feedback welcome.
(5) Exim currently can not use a string with embedded NULs, supplied in
configuration, for DB lookups, so you can *not* just use the gsasl
driver to talk directly to sasldb2 and cut over. It would be
informative to see expressions of serious interest by users who
want this, so that we can judge the importance of this work.
(6) I've no idea how to augment GSASL to integrate with Kerberos for
GSSAPI right now. The version of Heimdal I'm running disables
using KRB5_KTNAME from the environment for setuid binaries; there's
no way exported via gsasl to set the keytab. This affects Cyrus
too.
Heimdal doesn't let the keytab be set in appdefaults, only
libdefaults. *sigh* For folks using older releases of Heimdal,
gsasl might "just work" for you. Please let me know if it does.
(7) Nothing has been written for the test suite yet, so we have no
regression tests. I'm not willing to do this until we decide
whether to integrate for release.
Regards,
-Phil
--
https://twitter.com/syscomet
