At 07:05 PM 1/12/2005 +0100, Peter Sylvester writeth: > >The first thing is to make the dll's it stdcall friendly. :-) >(at least that the state of the art 3 years ago?)
Well, stdcall-friendly is not necessary for COM. I was thinking a nice wrapper DLL that implemented a COM server and made the appropriate calls into the real DLLs would be sufficient. I'm just much more concerned about the security implications in terms of the OS (particularly secured user environments) and IE's ActiveX and Active Scripting interfaces provide that might open a serious security loophole if an appropriate IDispatch-derived interface were implemented in the name of making VB usable with OpenSSL. As it is, I suspect developers already make a C++ ActiveX/COM wrapper for whatever functions they need and call it from their VB program (I know a lot of VB developers do precisely this with other non-VB compliant libraries, so this is a fairly common practice). The way they do it, however, is "security through obscurity" - hackers can't really guess what the CLSID is that is involved, so the system is secured purely by the way Windows issues GUIDs. The problem comes in with a common OpenSSL CLSID. This opens a huge loophole and makes it easy to write an Active Script that utilizes the raw COM object. Most VB programmers I know can do that. OpenSSL would have script kiddies galore overnight. This is why the topic has to be carefully discussed. My recommendation is to use a registry key in HKLM with a random value and combine that with another key stored in a file that is randomly generated at COM server installation. When the COM server is called, it has to be "unlocked" with the CLSID and the randomly generated key file data before it will accept anything else. This prevents Active Scripting except in scenarios where Active Scripting allows registry AND file access. Of course, in that case, all bets are off. If anyone has a better solution, I'd like to hear it. This is about the third request I've had for a COM interface to OpenSSL. And with "better support for C#" requests looming in the distance, a COM server would solve those requests as well. In theory COM can be handled cleanly via the interop handlers .NET provides. Yeah, I know. All of this COM talk is going to make everyone here very ill. So, I'll stuff a sock in it now and wait for people to comment on this. I'd rather not develop it (I have very minimal IDispatch-level development experience and wouldn't mind knowing more, but to learn on OpenSSL...), but I will if someone would be willing to help me integrate it into the build scripts and no one else is capable of handling it (I'm not _THAT_ familiar with the OpenSSL build process). Thomas J. Hruska [EMAIL PROTECTED] Shining Light Productions Home of the Nuclear Vision scripting language and ProtoNova web server. http://www.slproweb.com/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
