[exim] GNU SASL gsasl integration into Exim

Góra strony
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
Dla: exim-dev, exim-users
Temat: [exim] GNU SASL gsasl integration into Exim
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