Greetings!

Thank you for your explanation! But I'm sorry, I did not understand why the
behaviour depends on the config option's order. In case 3 and 4 the
behaviour differs but it is expected by me to be the same.

And how difficult will it be to write a patch for avoiding the "unlisted"
engines?

Thank you!


On Mon, Aug 26, 2013 at 4:45 PM, Stephen Henson via RT <r...@openssl.org>wrote:

> On Sat Aug 24 21:16:05 2013, beld...@gmail.com wrote:
> > Greetings!
> >
> > We have found an inconsistent behaviour of the openssl engine command.
> The
> > problem appeared in version 1.0.1d in case openssl is built with
> > --enable-shared.
> >
> > 1. When the config file does not mention the gost engine, the command
> > “openssl engine” does not mention gost among the loaded engines. If we
> > invoke “openssl engine gost”, it provides the necessary information about
> > the engine. Everything is ok.
> >
> > 2. If we provide the describing gost engine section in the config file
> > =============
> > openssl_conf = openssl_def
> > [ openssl_def ]
> > engines = engines_section
> > [ engines_section ]
> > gost = gost_section
> > [ gost_section ]
> > engine_id = gost
> > default_algorithms = ALL
> > ==============
> > “openssl engine gost” reports an error:
> > =============
> > GOST engine already loaded
> > 140403073971872:error:260B606D:engine routines:DYNAMIC_LOAD:init
> > failed:eng_dyn.c:521:
> > 140403073971872:error:2606A074:engine routines:ENGINE_by_id:no such
> > engine:eng_list.c:417:id=gost
> > ==============
> >
> > It seems understandable because the gost engine should be loaded
> processing
> > the config file, and the provided command tries to load the engine twice,
> > and the second load is prohibited.
> >
> > But the command “openssl engine” still does not mention the gost engine
> > among the loaded engines. Such a behaviour seems to be a bug.
> >
> > 3. If we provide the “dynamic_path” directive AFTER the
> > “default_algorithms” one,
> > (dynamic_path = path_to_openssl_dir/lib/engines/libgost.so) then either
> > “openssl engine gost” or “openssl engine” without extra parameters cause
> > an error:
> >
> > ===============
> > GOST engine already loaded
> > Error configuring OpenSSL
> > 140167406061216:error:260B606D:engine routines:DYNAMIC_LOAD:init
> > failed:eng_dyn.c:521:
> > 140167406061216:error:260BC066:engine
> routines:INT_ENGINE_CONFIGURE:engine
> > configuration error:eng_cnf.c:204:section=gost_section,
> name=dynamic_path,
> > value=/path/to/lib/engines/libgost.so
> > 140167406061216:error:0E07606D:configuration file
> > routines:MODULE_RUN:module initialization
> > error:conf_mod.c:235:module=engines, value=engines_section, retcode=-1
> > ================
> > This result differs from the behaviour of the 1.01c version. In the
> 1.0.1c
> > version the error did not occur.
> >
> > 4. If we provide the “dynamic_path” directive BEFORE the
> > “default_algorithms” one,
> > (dynamic_path = path_to_openssl_dir/lib/engines/libgost.so) then “openssl
> > engine” without extra parameters enlist the gost engine as loaded and the
> > either “openssl engine gost” provides the information about the gost
> engine.
> >
> > We suppose that this inconsistency can cause a more serious problems. For
> > example, we know that apache 2.2 gets a segfault using the gost engine
> with
> > openssl 1.0.1e (it did not happen with earlier versions), though we did
> not
> > investigate it yet.
> >
>
> What is happening is related to how ENGINE works with dynamically loaded
> engines in different contexts.
>
> If you do ENGINE_by_id("foo") it will first look for an engine called
> "foo" in
> the list of engines and if present return a reference to that.
>
> If "foo" is not present in the list it will then attempt to load a shared
> library engine for "foo". If it succeeds a reference is returned for the
> loaded
> engine. The new engine is NOT added to the list. It's this "unlisted" case
> that
> causes problems with the gost engine.
>
> If a second attempt is made to load "foo" then the code in the gost engine
> prevents this: its use of static variables means it isn't safe to load it
> more
> than once. There is AFAICS currently no way to just return a reference to
> the
> unlisted engine which was loaded before.
>
> The behaviour in the config file reflects this. If you just specify the
> engine
> id "gost" you get the dynamic load and unlisted engine behaviour. Then
> using
> "gost" on the command line tries to load it twice and you get an error.
>
> If you use "dynamic_path" the engine is loaded *and* added. Then subsequent
> attempts to use that engine work because it isn't loaded again: you just
> get
> the existing listed reference.
>
> The behaviour makes sense but it is not ideal. AFAICS the only way to
> handle
> this cleanly is to avoid the "unlisted" case and always add the engine to
> the
> list. Perhaps a new flag could be added to cover this.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
>


-- 
SY, Dmitry Belyavsky

Reply via email to