On 2012-05-16 at 20:51 +0100, Jeremy Harris wrote: > On 2012-05-16 17:33, Phil Pennock wrote: > > On 2012-05-15 at 11:08 -0400, Phil Pennock wrote: > >> The GnuTLS revamp is 3/4+ done, I need sleep now though. > > > > The GnuTLS revamp is ~done. It's pushed, anyway. > > Does this require the compile system to have some new GnuTLS > stuff installed? It doesn't build straight off for me:
CRAP. So, the current stable release of GnuTLS is 3.0.x; they only distribute with .xz or .lz compression extensions, which might explain why the OS packagers seem to still be on GnuTLS 2. The current 2 branch is GnuTLS 2.12.x. The old 2 branch is GnuTLS 2.10.x. GnuTLS 2.8.x is ancient. The previous Exim code was giving deprecation warnings on GnuTLS 2.12.x, and hard-codes a bunch of cryptographic information which belongs in the library but wasn't available when Exim's GnuTLS support was written. The current code, as I committed, gets rid of those deprecation warnings; I get one warning, about a file-descriptor int to pointer cast, but that's the API so we suck up that warning. The code gets rid of a bunch of crypto algorithm knowledge from Exim and lets GnuTLS do the right thing, cleanly. So we have a choice: continue to support ancient GnuTLS and get warnings and later errors on more current GnuTLS, or accept a new requirement of a "not too old" GnuTLS for the current Exim releases, if using GnuTLS. I've been going on the assumption that the only folks really on ancient GnuTLS are distros like Debian, who also maintain ancient Exim with patches, so they are not affected by this change until they also update Exim, when they can just update GnuTLS too. I think that we might have to say "if you need older libraries, use Exim with OpenSSL, which has had a more stable API". Thoughts? -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
