Author: Phil Pennock Date: To: Jeremy Harris CC: exim-dev Subject: Re: [exim-dev] GnuTLS status
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:
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".
This message was posted to the following mailing lists: