>>> Как реализовать ?
>>> С осени ищу мануалы, везде спрашиваю - в ответ тишина :(
> Это понятно, но усилиями nginx для вебсайта по 443 мне TLS 1.3
> удалось в centos 7 же прикрутить.
> Может быть как-то из исходников собрать exim и dovecot чтобы в них
> реализовать таки TLS 1.3 ?
> Но без пошагового мануала сам не смогу :(
Ну, если хотите, собирайте exim с необходимой версией openssl:
Extract the current source of OpenSSL. Change into that directory.
This assumes that `/opt/openssl` is not in use. If it is, pick
something else. `/opt/exim/openssl` perhaps.
If you pick a location shared amongst various local packages, such as
`/usr/local` on Linux, then the new OpenSSL will be used by all of those
packages. If that's what you want, great! If instead you want to
ensure that only software you explicitly set to use the newer OpenSSL
will try to use the new OpenSSL, then stick to something like
./config --prefix=/opt/openssl --openssldir=/etc/ssl \
-L/opt/openssl/lib -Wl,-R/opt/openssl/lib \
enable-ssl-trace shared \
enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers
On some systems, the linker uses `-rpath` instead of `-R`; on such systems,
replace the parameter starting `-Wl` with: `-Wl,-rpath,/opt/openssl/lib`.
There are more variations on less common systems.
You now have an installed OpenSSL under /opt/openssl which will not be
used by any system programs.
When you copy `src/EDITME` to `Local/Makefile` to make your build edits,
choose the pkg-config approach in that file, but also tell Exim to add
the relevant directory into the rpath stamped into the binary:
The -ldl is needed by OpenSSL 1.0.2+ on Linux and is not needed on most
other platforms. The LDFLAGS is needed because `pkg-config` doesn't know
how to emit information about RPATH-stamping, but we can still leverage
`pkg-config` for everything else.
Then build Exim:
sudo make install
exim -d-all+expand --version
and look for the `Library version: OpenSSL:` lines.
To look at the libraries _probably_ found by the linker, use:
ldd $(which exim) # most platforms
otool -L $(which exim) # MacOS
although that does not correctly handle restrictions imposed upon
executables which are setuid.
If the `chrpath` package is installed, then:
chrpath -l $(which exim)
will show the DT_RPATH stamped into the binary.
Your `binutils` package should come with `readelf`, so an alternative
is to run:
readelf -d $(which exim) | grep RPATH
It is important to use `RPATH` and not `RUNPATH`!
The gory details about `RUNPATH` (skip unless interested):
The OpenSSL library might be opened indirectly by some other library
which Exim depends upon. If the executable does have `RUNPATH` then
that will inhibit using either of `RPATH` or `RUNPATH` from the
executable for finding the OpenSSL library when that other library tries
to load it.
In fact, if the intermediate library has a `RUNPATH` stamped into it,
then this will block `RPATH` too, and will create problems with Exim.
If you're in such a situation, and those libraries were supplied to you
instead of built by you, then you're reaching the limits of sane
repairability and it's time to prioritize rebuilding your mail-server
hosts to be a current OS release which natively pulls in an
upstream-supported OpenSSL, or stick to the OS releases of Exim.
You can not use $ORIGIN for portably packing OpenSSL in with Exim with
normal Exim builds, because Exim is installed setuid which causes the
runtime linker to ignore $ORIGIN in DT_RPATH.
_If_ following the steps for a non-setuid Exim, _then_ you can use:
The doubled `$$` is needed for the make(1) layer and the quotes needed
for the shell invoked by make(1) for calling the linker.
Note that this is sufficiently far outside normal that the build-system
doesn't support it by default; you'll want to drop a symlink to the lib
directory into the Exim release top-level directory, so that lib exists
as a sibling to the build-$platform directory.