Rene Hollan wrote:
And how, pray tell, should OpenSSL know the threading model the
application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for
OpenSSL to require a reasonable threading API to implement SSL data
integrity, and for the application to provide an
On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
bad things happen and the
Er, my question about knowing the threading model was intended to be
rhetorical. Of course OpenSSL doesn't need to know the implementation, only
that one is available that fits its API.
The argument left then, is a philosophical one: is it OpenSSL's responsibility
to know what the standard
Then you provide an OpenSSL stub that these plugins actually link against that
lock the initialization of the real OpenSSL dlopen().
Ugly, perhaps, but you take the hit once. You are still left with the problem
of using the same threading model that these plugins use, but you have that
problem
On Jun 24, 2010, at 4:58 PM, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
I won't get into a personal attack.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
Hello,
I want to customize the default openssl library to operate only for SHA1,
SHA256, RSA and DSA. However when i am disabling most of the other options
of algos, DH, etc... i am getting errors while linking for EVP_aes_256_cbc,
EVP_aes_128_cbc, EC_KEY_free,... etc..
I am struggling to enable
Then that stub needs to be used by everyone that also uses OpenSSL, and for
Linux that means adding the stub to the LSB before any vendors adopt it, and so
forth...
Initialization of locks at library (or in the case of static linking,
application) load time is not rocket science and is being
On the openssl command page currently (2010-06-25) at
http://www.openssl.org/docs/apps/openssl.html,
the list of subcommands does not include the pkcs8 command.
(There is a pkcs8 subcommand page at
http://www.openssl.org/docs/apps/pkcs8.html,
and the rsa subcommand page at
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from the application. libraries cannot safely setup the
locking callbacks.
Just to make it clear why this is a problem imagine
