[EMAIL PROTECTED] wrote on 03/07/2008 01:21:08
PM:
> Within OpenHPI, the usage of the OpenSSL library is increasing,
> especially within plug-ins. (I am developing another plug-in that uses
> SSL, beside those already in the project.)
>
> OpenSSL requires some library initialization before use. Additionally,
> for a multi-threaded environment, the library requires that the user
> provide some thread-safe setup, implemented as a set of calls the user
> must make before using the library.
>
> It's difficult for a plug-in to do this. By the time the plug-in is
> initialized, other plug-ins may be called. Each plug-in doesn't know if
> it's the first, and therefore whether to do the initialization. It's
> possible that the SSL library initialization call can be performed
> multiple times (would have to check the SSL source code to be sure)
Would like to know for certain about this.
>, but it's unlikely that the thread setup can be done more than once,
looking
> at the implementation of those calls.
Is there a way to know if the openssl thread init has already been done?
Maybe by checking if there are any callbacks set?
>
> Beyond initialization, there may be opportunity to reuse SSL-based code
> between plug-ins. My experience in the last three months, trying to
> come up to speed on using SSL for reliable communication to managed
> hardware, is that it takes a fair amount of study and the code is
> tricky. To the extent that others can use the code, it would be nice to
> reuse it.
>
> Attached is a file of OpenSSL-based code that I propose we add to the
> OpenHPI infrastructure. All of the calls would be used by a plug-in
> that I hope to propose adding next week.
>
> If we don't want to add all this to the infrastructure, some can be kept
> in the plug-in. However, I'd suggest that we at least add the
> initialization code, along with it's thread-safe setup of the SSL
> library. This would be all the code up to the oh_ssl_init() function.
>
> We could call this SSL init code from the daemon when it starts, or each
> plug-in that wants to use SSL could call it. The code itself can be
> called multiple times as it's currently implemented.
Yes, the initialization code can be run from OpenHPI's initialization code
and we can create an ssl directory, like the snmp directory, that contains
your ssl convenience functions for others to use.
But before this, some questions:
- What number will CRYPTO_num_locks() return and do you need to create all
of them upfront? I'm worried about creating a bunch of lock instances
unnecessarily.
- Also, is it possible to use glib locking mechanisms, instead of directly
using pthread_*? OpenHPI uses glib locks for all locking needs and it
works on more platforms.
- One plugin won't use the SSL connection of another, so I don't see
thread-safety issues going across plugins. Am I right? Also, I don't see
any thread-safety issues with SSL connections unless a plugin uses the
same SSL connection from different threads. Is this how your plugins will
work? If so, would there be a problem locking around your SSL connections
using glib locks? (I think this page,
http://openssl.org/docs/crypto/threads.html, implies locking around ssl
connections is not enough).
- Is it really necessary to use dynlock callback/functions? According to
http://openssl.org/support/faq.html#PROG1, a minumum of two functions are
required. The notes at http://openssl.org/docs/crypto/threads.html say
that dynamic locks are currently not used internally in openssl.
--Renier
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
