Hey there,
On Sat, 25 Nov 2000, Dr S N Henson wrote:
> Eh? I'm talking here about the new_func() callback set up with
> RSA_get_ex_new_index(). An application using ex_data would want a new
> unique index. new_func() would get called during the initialisation of
> the ex_data and would get passed a pointer to the parent RSA structure
> and a few other things. It should then be able to modify ex_data based
> on the parent RSA structure.
Oh I see, sorry I got my wires a bit crossed there. Hmm ... and that's
given me another idea about how to tackle the particular case I face -
thanks.
> The only potential problem with that is that an RSA structure can be
> created and no actual crypto done with it which is why some of the
> internal code does things on the first use, albeit rather badly.
Agreed, but I find that sort of thing kind of vile. Every piece of code
that might *use* the key has to allow for the fact that initialisation
hasn't been done or was incomplete - it really defeats the purpose of
having "new" and "free" hooks. But anyway, I've been taking a sort of
hybrid approach - namely that the init() and finish() handlers are
responsible for allocation and deallocation issues; which make sense to me
as they're called from the RSA_new() and RSA_free() functions that do the
same job for the other RSA structure elements. However, the per-key
configuration of "contexts" is performed the first time the complete
structure is used - at which point one hopes that the RSA structure
actually contains some meaningful data. Of course I'd been butchering the
intention of the CRYPTO_EX_DATA structure by simply stuffing my context
onto the structure's underlying stack and avoiding the higher-level
ex_data stuff altogether - probably not a good idea.
Doing allocation during "new" rather than on "first-use" also provides a
separation between arbtirary context stuff (handles, file-descriptors,
environment stuff, etc) and key-specific context stuff (indexes or
identifiers for individual keys, caching of key-derived data, etc). The
former happens on creation, the latter happens on first-use.
> I agree that init() isn't particularly useful. It would be much better
> if it, or an equivalent, was called when the RSA structure contained
> more useful info.
Yep, but having an init() handler in RSA_METHOD might at least be usable
for *something* if the location these custom methods should be storing
things has been initialised when it gets called! Otherwise I'm at a loss
to understand what an init() handler could do at all that complies with
the structural design of RSA et al - ex_data is supposed to be *the* place
to stick custom data and it's untouchable at that point.
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.
Thoughts?
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
