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
pgpfM1IMF0pVU.pgp
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
