Greetings!
After I have looked into the processing the default_algorithms and
dynamic_path directives, I understand what you mean.
Thank you!
Can you provide a guideline for writing the patch which will allow to add
the engine to the engine's list always?
Thank you!
On Mon, Aug 26, 2013 at 5:48 PM, Dmitry Belyavsky <beld...@gmail.com> wrote:
> 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
>
--
SY, Dmitry Belyavsky
