Geoff Thorpe wrote:
> 
> 
> Unless I misunderstand the RSA_get_ex_new_index() stuff - calling it to
> just get an index from inside the init() handler the first time it happens
> (and passing NULL callbacks) and then using CRYPTO_[set|get]_ex_data with
> that index should be functionally equivalent to specifying callbacks in
> the call? *Except* that it seems that specifying the RSA's ex_data
> callbacks is a global catch-all initialisation hook, whereas the init()
> handler is a per-method initialisation hook. Ie. if you're opening RSA
> keys with various different RSA_METHODs, how is the callback to know which
> ex_data structures it should be initialising? Of course one could then
> drill back through the "parent" pointer, hack into the method, and test it
> for a match, but that's starting to get a little too "creative" for my
> tastes.
> 
> Hmm ... if I'm right about this (and please straighten me out if I'm not)
> then I'd still prefer to simply have the CRYPTO_EX_DATA initialised prior
> to the init() call and then do it from there - then you know you're inside
> the right method at the right point in time rather than throwing callbacks
> out into the ether and trying to get a grip on the situation when your
> callbacks come back to you later on.
> 

You normally call the RSA_get_ex_new_index() at startup and then store
the index somewhere static. Then use that for later access. It then ends
up calling the various ex callbacks whenever RSA_new() and RSA_free()
are called, the dup() callback never gets called for most things.

In this case though if you want different things on a per method basis I
agree that init() is the place to do it and ex_data should be
initialised earlier on.

Then of course you'd better look at what happens in RSA_free(). The
ex_data structure is destroyed *before* the finish() method is called.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to