Dr Stephen Henson wrote:
>
> >From time to time someone needs to pass a parameter to a passphrase
> callback. For example the prompt for the password can be set to a
> meaningful phrase or the passphrase itself could be set by this method.
>
> Currently this isn't directly possible and the only solutions are messy.
>
> IMHO it's about time this issue was resolved one way or the other.
>
> There are several possible solutions, some break existing code and
> others might be considered a bit "naughty". But first a bit more info
> about the way things are handled...
>
> All the passphrase callbacks are function pointers which look like:
> int pem_password_cb(char *buf, int size, int rwflag);
>
> 'buf' is the buffer to write the passphrase to, 'size' is the maximum
> length of the passphrase and 'rwflag' is set to '1' if the passphrase
> should be verified by asking for it twice (e.g. when setting or changing
> a passphrase as opposed to checking an existing one).
>
> They return the length of the password or a value <=0 to indicate an
> error.
>
> Typically a callback is passed to a function like this:
>
> EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, pem_password_cb *);
>
> OK enough backround. Here are a few possible solutions.
>
> 1. Just add an extra parameter. With this method the callback would
> become:
>
> int pem_password_cb(char *buf, int size, int rwflag, void *arg);
>
> and would be called like this:
>
> EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x,
> pem_password_cb *, void *arg);
>
> This main problem with this is anything existing code calling
> PEM_read_PrivateKey() should choke with a compilation error. The fix is
> trivial though: set the extra parameter to NULL and add an ignored
> parameter in the callback (if used).
>
> This does at least have the advantage that it solves the problem and
> catches any code using the "old way": that is everything at present.
>
> 2. Add a set of extra functions:
>
> EVP_PKEY *PEM_read_PrivateKey_ex(FILE *fp,EVP_PKEY **x,
> pem_password_cb_ex *, void *arg);
> int pem_password_cb_ex(char *buf, int size, int rwflag, void *arg);
>
> This might be considered overkill, would double the number of PEM
> functions needed and have lots of PEM 'legacy' functions using the old
> method that would have to stay. It would however retain compatability
> with existing code.
>
> 3. Do something evil with the cb parameter...
>
> EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, void *x);
>
> This has a companion "default callback":
>
> int default_pem_callback(void *x, char *buf, int size, int rwflag);
>
> This needs a bit more explanation. Any function calling
> PEM_read_PrivateKey() in the "old way" will end up calling the
> default_pem_callback() which retains the old behaviour: treating 'x' as
> a passphrase callback in the "old way". Anything that wants to pass
> parameters to the callback can replace the default_pem_callback() and
> interpret the 'x' parameter in any appropriate way.
>
> This does however lose typechecking of the 'x' parameter and is a bit
> awkward to use. Interpreting a void * as a function pointer might also
> be a potential problem.
>
> This does however have the advantage that existing code will still work
> and the neccessary functionality is available.
>
> Anyway thats three options, none of which IMHO is ideal. Any alternative
> solutions or comments anyone?
I think 3 is too disgusting to contemplate. 1 is OK with me: we
regularly break all existing code, anyway (speaking of which, I tried to
get demos/selfsign.c going the other day, but X509v3 support has changed
so drastically I couldn't easily figure out how!). If you are concerned
about existing code, then I'd vote for 2, but I'm not hugely keen on the
precedent or the bloat.
The other possibility I can think of is to add an "extra data" pointer
to EVP_PKEY instead.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
