On Wed, 2020-02-26 at 12:51 +0300, Mikhail Novosyolov wrote:
> Hello Mimi, thanks for feedback.
> 25.02.2020 16:44, Mimi Zohar пишет:
> > On Sun, 2020-02-16 at 14:10 +0300, Mikhail Novosyolov wrote:
> >> LibreSSL in most cases can be used as a drop-in replacement of OpenSSL.
> >> Commit 07d799cb6c37 "ima-evm-utils: Preload OpenSSL engine via '--engine' option"
> >> added OpenSSL-specific functions: "engines" were removed from LibreSSL long ago.
> >> Instead of requiring to attach GOST support via an external library ("engine"),
> >> LibreSSL has build-in implementation of GOST.
> >
> > OpenSSL had a builtin support for GOST, which was dropped. From the
> > OpenSSL news "Changes between 1.0.2h and 1.1.0":
> >
> > The GOST engine was out of date and therefore it has been removed. An up
> > to date GOST engine is now being maintained in an external repository.
> > See: https://wiki.openssl.org/index.php/Binaries ; . Libssl still retains
> > support for GOST ciphersuites (these are only activated if a GOST engine
> > is present).
> >
> > Please update the patch description to reflect the reason for OpenSSL
> > dropping GOST builtin support, while LibreSSL continues to build it
> > in.
> The reasons why OpenSSL decided to do it are out of my scope, I can
> just write that OpenSSL had GOST, then dropped it, then gost-engine
> appeared as an OpenSSL plugin and that LibreSSL has GOST built in
> and dropped engines API after forking from OpenSSL. Will it be OK?
The question is whether LibreSSL is using the back level version of
GOST that OpenSSL dropped or has it been updated? The patch
description should be updated accordingly.
> >> diff --git a/src/evmctl.c b/src/evmctl.c
> >> index 3d2a10b..f6507c1 100644
> >> --- a/src/evmctl.c
> >> +++ b/src/evmctl.c
> >> @@ -62,7 +62,10 @@
> >> #include <openssl/hmac.h>
> >> #include <openssl/err.h>
> >> #include <openssl/rsa.h>
> >> +/* LibreSSL removed engines */
> >> +#ifndef LIBRESSL_VERSION_NUMBER
> >> #include <openssl/engine.h>
> >> +#endif
> >
> > According to the LibreSSL wiki, both OpenSSL and LibreSSL may be
> > installed on the same system in separate directories. Instead of
> > using LIBRESSL_VERSION_NUMBER, consider defining an autotools option.
>
> LibreSSL can be used either as a drop in replacement of OpenSSL or
> can be installed to a separate prefix.
>
> What do you suggest to do with an autotools option? To define a
> prefix where libssl/libcrypto is, e.g. /usr or /opt/libressl? It may
> be useful. But, in my experience of building curl and other programs
> with LibreSSL from a custom prefix, any heaurestics in configure.ac
> cause much more troubles than profit, I had to hack curl's
> configure.ac to stop it from picking OpenSSL.
>
> Right now the only line which detect libcrypto is
> "PKG_CHECK_MODULES(LIBCRYPTO, [libcrypto >= 0.9.8 ])". If we make an
> autotools option, we will have to somehow handle situation when
> headers and/or pkgconfig files are not in the prefix, like curl does
> (https://github.com/curl/curl/blob/master/configure.ac#L1642). Let's
> avoid such a bicycle. I had to hack it to build curl with libressl,
> and many people on the Internet complain that it works incorrectly
> in case of cross-compilation. The same problems will occure in ima-
> evm-utils.
>
> Right now I build ima-evm-utils like this:
> export LIBCRYPTO_CFLAGS="$(pkg-config --cflags-only-I --libs-only-L
> libressl-libcrypto)"
> ...where libressl-libcrypto is a not upstream name of the *.pc file,
> I renamed it from libcrypto.pc to libressl-libcrypto.pc. It works
> perfectly. There is no need in inventing a bicycle in configure.ac,
> I am pretty sure.
Somehow this information needs to be conveyed to others. Perhaps it
could be hidden behind an "--enable-libressl" option. Minimally
please include this in the patch description.
Mimi
