[geoff - Sat Feb 15 21:48:27 2003]: > The problem is nonetheless still there, and I am looking at it.
OK, I've taken a further look - and some of the issues this problem have raised apply to other code too (eg. RSA and DH for sure, perhaps others). The fact that these METHOD's have "protected" virtual functions, forgetting for a moment where are in C, is problematic when trying to handle falling back to other implementations - as you say, if you try to fall back to a different implementation, it will still risk calling other functions from the key's METHOD table. I worked around this once in the "keyclient" ENGINE by temporarily changing the key's METHOD table, but that workaround is no good for the general case. I've attached a diff that I think addresses the problem but I'll need to consider the consequences a bit more in terms of how this could affect existing (and 3rd party and future) DSA implementations. Could you please try this out with your ubsec support and see if the handling of fallback to software is better (at least with respect to segfaults)? Cheers, Geoff -- Geoff Thorpe, RT/openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
