Damien Miller <[EMAIL PROTECTED]> wrote:
> I want to add the facility to pass user data to password callback
> functions. e.g.
>
> RSA *PEM_read_bio_RSAPrivateKey(BIO *bp, RSA **x, pem_password_cb *cb)
>
> becomes
>
> RSA *PEM_read_bio_RSAPrivateKey(BIO *bp, RSA **x, pem_password_cb *cb, char
*user_data)
>
> and
>
> typedef int pem_password_cb(char *buf, int size, int rwflag);
>
> becomes
>
> typedef int pem_password_cb(char *buf, int size, int rwflag, char
*user_data);
It's good to see this question raised again!
I had exactly this case in mind in a discussion a couple of years ago with EAY
on passing external data to callbacks. At the time, the focus was primarily
on what form the external data should take and what structures should carry
it, rather than specifically how to pass it down to which callback. The
result in the end was that the forms for expressing external data are now
quite rich, but it seems the callback code itself never quite did get changed!
While waiting for these details to be worked out, I had to get going on my
application, and the quick hack I did was just what you propose, with the
minor difference of using type "void *". It worked well enough to keep me
going, but on reflection I'm convinced it would lead to a more unified
solution if an SSL_CTX were passed instead of an anonymous pointer. Recall
that this structure is uniquely used to identify the callback function
itself, and it follows that any external data needed by the callback can be
bound here also, without loss of generality. Indeed I have been given to
understand that the ex_data field of this structure was conceived for just
this sort of extensibility.
Thus, we don't really need to add a separate field for callback data to the
structure, and we also don't need to pass down a new kind of anonymous
pointer used only for this one purpose. It took me awhile to think this all
through, and I confess that at the time it seemed a lot easier just to do
the "void *" hack, but in the long run it makes more sense to use the data
types already in the API. Also since then, work has been done to define
types and accessor macros so that we now have relatively little to do in
order to extend the callback one way or another. I think the only real
debate is in how it should look.
I do believe, in any case, that this issue should be nailed down solidly
while the library is still in beta. Before I propose a solution formally,
is there any more discussion on what the password callback really needs?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
