On Thu, Aug 12, 2021 at 09:51:53AM +0100, Jeremy Harris via Exim-dev wrote:
> > With OpenSSL 1.0.2 long EOL, is there any chance that newer versions
> > of Exim could set the floor OpenSSL version to 1.1.1 and migrate to
> > use the built-in DANE support? I'd can offer some help to get you
> > there, and then retire the standalone library for good...
>
> I tried (rather briefly) to reactivate my openssl build environmentm
> so as to see what works and doesn't under the current nearly-3.0.0
> OpenSSL. But it seems to be bust, and it's one of those things that
> is far too convoluted to work on.
FWIW, provided one is willing to ignore some deprecation warnings,
Postfix builds with 3.0.0, with just one change to constify an EC_KEY
object, used to access curve metadata for logging. The patch to deal
with deprecations is somewhat more invasive, but not too bad, just had
to rewrite the DH parameter loading.
> I'm quite expecting Exim to start breaking horribly, when 3.0.0
> appears on real systems.
Yes, there's a non-trivial chance it may not compile without some
changes. More mundane applications are expected to not have issues,
but Exim has the low-level code for DANE, and perhaps other tweaks
that make it much less of a vanilla OpenSSL application.
> I've occasionally considered working on a move to the native DANE
> support, under both OpenSSL and GnuTLS (which we officially support).
> But I expect it to be a whole bunch of work, and invasive to the point
> of horribly complexifying the Exim codebase.
You'd be able to drop the "danessl" library. The native DANE support is
fairly simple to use. Just tell the OpenSSL library the TLSA base
domain (effective SNI and hostname for namechecks) and which TLSA
records to use and then let it do all the work.
> (Likewise, so will fixing whatever 3.0.0 breaks for us, since we
> cannot drop support for earlier versions.)
My Postfix snapshot supports both 1.1.1 and 3.0.0. We dropped 1.0.2
support in Postfix 3.6 released in April, and skipped 1.1.0 (not a
stable release and no longer supported).
> You might guess that my enthusiasm is rather low, here.
Sure, but it probably just needs to get done... I can help with
suggested code snippets to replace things that no longer work as you run
into them.
> The there's the LibreSSL question. I've never found any decent docs
> for it; we only discover issue where it differs from OpenSSL
> one-at-a-time. Currently we manage this with a raft of feature-macros
> just like we have to for OpenSSL versions. Do you know if LibreSSL
> has the same DANE APIs as OpenSSL?
No, there's no DANE support in LibreSSL. My advice would be to drop
LibreSSL support. But if you stick with LibreSSL (1.0.2 on life support
forever), then by now it needs to become a completely separate TLS
support module just like GnuTLS. The list of differences is growing
to a point that conditional compilation macros would make the code too
difficult to understand/maintain.
> As far as dropping support for earlier OpenSSL versions goes: there is
> at least one system in the buildfarm not operated by me and running
> with OpenSSL 1.0.1s - a Solaris 10. I assume that means there is at
> least one person out there still interested in operating Exim on
> systems of that vintage, even though the OpenSSL project calls it End
> Of Life.
Sure, but at some point that person would have to settle for running
vintage Exim as well. There are no longer any public releases of
bug fixes for 1.0.2, it is a dead branch (IIRC since Dec 2019).
At some point it is time to move on...
--
Viktor.
