Hey all, I've been using openssl 0.9.8k on Win32 and have run into a corner case when my app is installed into a directory containing non-ASCII characters. It tries to load a cert store using SSL_CTX_load_verify_locations() and it fails to read the file.
It turns out that this is a common problem on Win32 because of the use of the fopen() command, which only supports ASCII. Other open source projects have worked around this by trying fopen() first, then upconverting the path and mode strings to UTF-16 and trying again with _wfopen() (which does work with any valid path you could possibly throw at Windows.) Here's the tale of a different project that had to deal with this problem. http://www.mail-archive.com/[email protected]/msg16601.html As you may notice, this will assume that any path that fopen() fails on is in UTF-8. I think that's a safe bet considering that this is how things work on POSIX platforms nowadays as well. I've patched the BIO subsystem to do this and it works great for me. However, I can't toss the patch at anyone just yet because I have to clear it with my employer - though it is an easy fix. I notice that most of the 'apps' use fopen(). I think the best fix would be to wrap all calls to fopen in the whole source tree with platform specific shims that can deal with the added logic on Win32. (On this note, I also saw many places where 'vms_fopen' is used, and I feel like that could benefit from a global wrapper as well.) Thoughts? Please CC me on replies, as I'm not subscribed to the list. -Josh ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
