2009/8/7 Dave Thompson <dave.thomp...@princetonpayments.com>: >> From: owner-openssl-us...@openssl.org On Behalf Of Alexander Lamaison >> Sent: Thursday, 06 August, 2009 09:12 > >> I'm trying to avoid passing any C-runtime objects (such as a >> FILE*) across the OpenSSL DLL boundary. This is unsafe as >> the two DLLs may be using different runtime instances which >> causes crashes on Windows. > > FYI in recent (~2years?) versions of OpenSSL, there is another way > to handle this: compile OpenSSL_Applink (include/openssl/applink.c) > into your app; that directs OpenSSL's I/O calls to correct CRT.
I our case (the libssh2 library) we don't have an EXE to compile OpenSSL_Applink into (you cant just compile it into a DLL because it doesn't get called. Also I read that OpenSSL_Applink is mainly for use when application: http://archive.netbsd.se/?ml=openssl-dev&a=2005-12&t=1552483 (2nd message). New OpenSSL clients should avoid FILE* functions entirely. > There's a third way in some cases -- don't have OpenSSL access > the file(s) itself, but instead app reads the file and pass in > the data, and/or get out the data and app writes the file. This is how it is being done at the moment but we're capping the read length at some arbitrary maximum to prevent the user accidentally specifying a large file and allocating gigabytes of memory. This doesn't seem 'neat' and when OpenSSL reads the files itself it just reads as much as it needs as it parses them. Hence, my plan to use BIO_new_file. >> Also, I came across the OPENSSL_NO_FP_API preprocessor >> definition which seemed to prevent accidentally calling an >> API function that allowed unsafe FILE* passing. However, I > > I'm not sure that's its purpose; it's not documented that I can see, > and maybe no longer supported; per below it clearly wasn't > very often tested (and perhaps used). Ok. So I'll just ignore this one. Even more confusingly, there's another one called OPENSSL_NO_STDIO. I'll just have to be careful not to call any FP functions. > OTOH you can build OpenSSL normally and just never call *fp*. > Using a DLL this is easy to verify; just do (MS) dumpbin/imports, > and I think (sysinternals-now-MS) dependency-walker can do it too. Hmmm. I don't entirely follow. I'm familiar with dependency-walker but I don't see how I can use it to verify no FP function calls. Many thanks for your help :) Alex Lamaison ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
