Re: [PATCH] ima-evm-utils: remove redundant call to OpenSSL_add_all_algorithms

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2019-01-30 at 20:54 +0300, Vitaly Chikunov wrote:
> On Wed, Jan 30, 2019 at 08:44:25AM -0800, James Bottomley wrote:
> > On Wed, 2019-01-30 at 19:12 +0300, Vitaly Chikunov wrote:
[...]
> > > There is preferred "easy" method of [system wide] loading of
> > > gost-engine "by default" just by changing openssl.cnf like this:
> > > 
> > >   https://github.com/gost-engine/engine/blob/master/example.conf
> > > 
> > > After that change all openssl (and linked) tools understand GOST
> > > algorithms without needing options like `-engine gost`.
> > 
> > This means that you turn the gost engine on by default in the file
> 
> This is how most gost users are suggested to use it.

Well, no, this is how Russian Government people use it because gost
implements the mandatory aspects of their encryption standard.  If you
work for them you want gost all the time for everything.  So it's the
suggested way for that class of users.

However, that's not how a casual non-Russian user would want it. 
They'd only want gost if they specified the streebog hash.  And if we
advertise the hash (as we do because you added it to the help) they
should have a reasonable expectation of its working easily.

> > > This works unless tool is compiled without OPENSSL_LOAD_CONF and
> > > it calls OpenSSL_add_all_algorithms() instead of
> > > OPENSSL_add_all_algorithms_conf(). Which is frequently the
> > > default, (because there is too much methods of openssl
> > > initialization and people may not understand all intrications for
> > > all options.) In that case we try to persuade tool author to
> > > change the way openssl is initialized.
> > 
> > What I'm saying is that modifying config files is really difficult
> > for most users.  So, if you want ima-evm-utils to work out of the
> > box with the Streebog hash it needs to have no dependent
> > requirement on config files, which means you need to add the call
> > to ENGINE_set_default()
> 
> I implemented two methods of loading engine for evmctl (via config
> and via --engine option).  There is no problem with --engine option
> for Streebog, AFAIK.

Can you try it with a vanilla (non gost modified) openssl.cnf file to
verify?  I think you require the ENGINE_set_default() call but it may
be that a non-standard hash name will cause a search of the engine
added hashes.  OpenSSL has badly documented defaults, so I usually
chase that through the code, but in this case a simple experiment will
tell us.

>   We are talking about config method, which would be
> default for the most users.
> 
> (Your suggestion is still good for my next patch what implements PKEY
> instead of RSA, for EC-RDSA signatures. Thanks! I will add it.)
> 
> > This isn't about how you usually do it, it's about making these
> > additions usable for average users.
> 
> Config method of loading gost engine is not how I usually do it, but
> how most gost users use it (and suggested to use it). This isn't some
> marginal use case. They just modify `openssl.cnf` once (manually of
> via script) and all relevant ssl tools "magically" start to
> understand gost algorithms without any additional options. This would
> be very not user friendly if for every network tool that supports ssl
> they should specify `--someoption gost`.

Right, I'm not saying disallow that.  The Russian crypto case is
certainly a valid class of user.  What I'm saying is *don't* require
this config setup for other non-Russian crypto users because they won't
be familiar with it.

> `--engine` option is just supplementary for advanced or occasional
> users. It continues to work (for Streebog) if
> OpenSSL_add_all_algorithms call is removed, but breaks if
> OPENSSL_add_all_algorithms_conf is removed, probably, need to call
> ENGINE_load_builtin_engines in that case.
> 
> All this make initialization more complicated instead of single call
> to OPENSSL_add_all_algorithms_conf().

Yes, but it's acceptable to make our life more complex if it makes life
simpler for the end user.

> > That doesn't stop you from adding further mods via the config
> > files, but it does mean that if a random user installs evmctl and
> > types
> > 
> > evmctl -e gost -a streebog256 ...
> > 
> > it will just work instead of failing with an obscure error because
> > the default config file is wrong.  I actually think for usability
> > you should tie the hash and the engine together so a user can just
> > type
> > 
> > evmctl -a streebog256 ...
> > 
> > And the tool will automatically try to load the gost engine and
> > tell you if it's missing.
> 
> This is interesting idea. (But this probably will fail for GOST
> keys/certificates.)

Gost certs should identify the streebog hash, so in theory we can
examine the OIDs and see we need the gost engine to process them.  I'm
certainly not saying do this, I'm just giving it as an example of how
to make life easier for users.

James