On 2018-04-09 at 08:14 +0200, Kirill Miazine via Exim-users wrote: > Hi, Phil
> * Phil Pennock via Exim-users [2018-04-08 17:24]:
> [...]
> > We've said "we only support versions of OpenSSL supported by the
> > upstream project", so now it's time to take advantage of that.
>
> So LibreSSL is not supported officially, is it? If it breaks, it breaks,
> and Exim should be built with OpenSSL?
Exim is a volunteer project, we live on patches. Our history is full of
features and support provided by drive-by patches, which were massaged
to be somewhat maintainable. Jeremy, Todd and Heiko have done a lot of
work rounding out our test suite to remediate some of the negative
consequences of that.
When working across multiple choices of provider for a given interface,
the usual approach is a bridge pattern, where we stick to one simpler
subset of functionality and plugging in other providers can satisfy that
bridge.
If LibreSSL is going to continue to diverge, and if anyone cares enough
to provide patches, then we could easily have a `tls-libressl.c` file
which _implements_ the `SSL_CONF_cmd()` API, dispatching relevant
text-based calls to the correct feature-specific SSL_CTX manipulating
functions.
As someone maintaining an application built on SSL libraries, and
needing to provide tuning to multiple end-sites, while doing too much
already in terms of propagating SSL options and such like, I think that
the SSL_CONF_cmd() API is a great idea. That it would let us change our
configuration to be more extensible, more flexible, easier to maintain
and generally more _useful_, for _less_ ongoing maintenance, is A Good
Thing. I encourage folks to look carefully at what I proposed and how
easy it is to implement with this API and consider if their library
should support it too.
At present, we "support" GnuTLS and OpenSSL. If anything else happens
to work, that's great for you. If it break, you can either keep the
pieces or provide patches to make it work again, in a way which is
maintainable going forward.
We've been saying, including on the -announce list, for the past few
_years_ that we'll only support versions of OpenSSL which are supported
upstream and that "some release Real Soon Now" would break compatibility
with older versions.
