"Stephen Henson via RT" <r...@openssl.org> wrote:
All i can parse from your answer is that the statement that is
long in OpenSSL documentation and was referred to by Rich Salz
(unless i'm mistaken) in a different #issue, namely the following
paragraph from OPENSSL_config(3):
It is strongly recommended that all new applications call
OPENSSL_config() or the more sophisticated functions such as
CONF_modules_load() during initialization (that is before starting any
threads). By doing this an application does not need to keep track of
all configuration options and some new functionality can be supported
automatically.
|On Fri Dec 12 17:52:22 2014, sdao...@yandex.com wrote:
|> Hello,
|>
|> while following Rich Salz's suggestion to make use of
|> CONF_modules_load_file() i stumbled personally over the
|> restriction that only a global openssl.cnf seems to be supported.
|> There is no support for automatic loading of a $HOME/.openssl.cnf
|> on top of the global version.
|>
|> And whereas setting of $OPENSSL_CONF could be used and
|> communicated to users to achieve the desire, doing so actually
|> replaces inclusion of the global openssl.cnf, which likely not
|> results in the wanted effect!?!
|> While here, it doesn't seem possible to _forbid_ use of
|> $OPENSSL_CONF (from reading the manual)?
|> If that is true then i would ask for an additional
|> CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too.
|>
|
|While that could be done it would be a while before the new \
|feature appeared in
|released versions of OpenSSL. You can get finger control over \
|the configuration
|using existing APIs with current versions of OpenSSL.
|With CONF_modules_load_file() if the passed filename is not NULL then that
|value is used only. You only get the use of a local or system openssl.cnf if
|the filename passed is NULL. So if you pass the path to a \
|"system" openssl.cnf
|it cannot be overridden by the OPENSSL_CONF environment variable.
How do i get a notion of the actual path in order to prevent that?
I'd like the openssl-conf package provided openssl.cnf with the
newest global protocol and cipher specifications, and i don't want
noone to mess that up.
Except that i want that a user may add something on top.
Btw. i also once had a failed attempt with resource files, along
the lines
* [!/immutable/group]
* [#10#/group/with/limit]
* !immutable_entry=some value
* (int)refresh_time=60
i.e., with things that were fixateable on a global level, even if
a user provided his own ~/.xyrc.
(With compiled-in default configs etc., it became much too bloated
and never sprung into existence. But only a `!' prefix may be
worthwile for something security related as OpenSSL is.)
|The function CONF_modules_load can be passed the CONF structure \
|to use directly
|which doesn't need to come from a file at all. It could be \
|from multiple files,
|hard coded data or something strange like the Window registry (if the
|appropriate code was written to add the data to the CONF structure).
Wise words spoken. ("Could".)
--steffen
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
