Re: [PATCH] ima-evm-utils: Fix compatibility with LibreSSL

[Vitaly Chikunov <vt@altlinux.org>]

Mimi,

On Wed, Feb 26, 2020 at 11:28:14PM -0500, Mimi Zohar wrote:
> 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.

AFAIK, LibreSSL is using independent implementation of Streebog. It
wasn't exist in OpenSSL before split and different from what is in
gost-engine (also having different authors).

I don't really understand reason to know implementation history, if,
as library users, we should be enough to know they have compatible APIs.

Thanks,