RE: Building an exportable OpenSSL application
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Wednesday, 17 October, 2012 09:47 snip [Using ShiningLight Windows build] If you link with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking. If you link with lib/VC/static/* you get static linking. Thanks. Did not exactly understand that point. I am in fact using lib/VC/*. I may change that to MinGW so that the intention is more obvious. I wouldn't advise that. The (two) VC directories are built for VC++ and the MinGW directory is built for MinGW. MinGW (unlike Cygwin) tries to be mostly pretty much compatible with VC++ but I wouldn't rely on it being totally so. Better to use as designed. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Building an exportable OpenSSL application
OK. Misunderstood the earlier answer. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 18, 2012 12:26 AM To: openssl-users@openssl.org Subject: RE: Building an exportable OpenSSL application From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Wednesday, 17 October, 2012 09:47 snip [Using ShiningLight Windows build] If you link with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking. If you link with lib/VC/static/* you get static linking. Thanks. Did not exactly understand that point. I am in fact using lib/VC/*. I may change that to MinGW so that the intention is more obvious. I wouldn't advise that. The (two) VC directories are built for VC++ and the MinGW directory is built for MinGW. MinGW (unlike Cygwin) tries to be mostly pretty much compatible with VC++ but I wouldn't rely on it being totally so. Better to use as designed. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Building an exportable OpenSSL application
Just two small general NITs (Sort of off-topic, as the OP seems to know this): On 10/17/2012 2:53 AM, Dave Thompson wrote: ... - implicit dynamic linking, with .lib on Windows containing stubs that point to code (and sometimes data, but that's usually poor practice) in a .dll. This type of .lib is called an import library. NIT 1: On Windows, modern (post 1998) stub .libs often contain only a data description of the symbol and how it is listed in the DLLs export table, the actual stub/glue code is then generated on the fly by the linker. Also the stubs have two parts: A single pointer variable tagged to be filled in at runtime by the loader, and an optional jump stub used by code that had not been compiled to know this item would be imported (via __declspec(dllimport) in the header telling the compiler to implicitly reference the pointer variable inline). NIT 2: Importing data is not bad practice per se, but typically requires thecompiler and linker to both know that this is an imported data address,which cannot be serviced via a jump to real address proxy stub likefunctions can. This can expose bugs and shortcomings in the toolchain(compiler/linker). For the PE file format (Win32/Win64/WinCE): Many versions of the GNU toolchain play nasty tricks with this file format due to a misunderstandingof its more subtle points. For Visual C, the special delayload linker/runtimefeature does not work well for data items, as it generates special stubs that loadresolve the symbol on first call, and this only works for function symbols. For the old Borland/Turbo C/C++ tools there was a bug in some versions messing up the import of the stdin/stdout/stderr variables from the C runtime DLL, causing even very simple programs (like Hello, stderr) to crash. Because of this (and because some platforms just don't support it at all), it is good practice for portable DLLs to export a functions which returns the address of the data item, thus working around all this breakage. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Building an exportable OpenSSL application
Thanks much. Knew all of that from a technology point of view and from other platforms but did not know the proper Windows/UNIX terms. I was worried by the assertion that static linking to .lib's and the use of DLLs was inconsistent. at runtime the OS finds those .dll's using moderately complicated search rules, which can be an issue if you have multiple versions in different places Yes, and I found that various products I have licensed or trialed over the past few years have each installed their own OpenSSL DLLs of various versions in various places. SSLeay_version(SSLEAY_VERSION) is a big help in figuring out which DLL is actually getting used. If you link with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking. If you link with lib/VC/static/* you get static linking. Thanks. Did not exactly understand that point. I am in fact using lib/VC/*. I may change that to MinGW so that the intention is more obvious. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Tuesday, October 16, 2012 5:53 PM To: openssl-users@openssl.org Subject: RE: Building an exportable OpenSSL application From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Tuesday, 16 October, 2012 11:41 If you are linking to OpenSSL DLLs, then your application isn't statically linked against OpenSSL. .lib files can simply be references to exports in .dll files. This is an important point. Can we be absolutely clear? My picture of how this works is that the .lib files contain small stubs so that while the application code has the illusion of making a static call to SSL_whatever() in reality that is a tiny stub that actually calls code in a DLL. There is no functional code in the .lib, only stubs that link to functional code in the DLLS. Am I wrong? This is a critical point. Yes, plus. To be exact, there are really three ways: - traditional (since like 1950) static linking, with .lib on Windows or .a on Unix containing actual code and static data. The linker copies referenced code and data to your Windows .exe or Unix executable. - implicit dynamic linking, with .lib on Windows containing stubs that point to code (and sometimes data, but that's usually poor practice) in a .dll. This type of .lib is called an import library. The linker pulls the stubs into your .exe and and also includes a list of the .dll files; at runtime the OS finds those .dll's using moderately complicated search rules, which can be an issue if you have multiple versions in different places, although in my (limited) experience the simple solution of putting .dll's in the same directory as the .exe always works. On Unix similar but there's no import library; you link directly against .so .sl etc, and the linker puts the imports in the executable. - explicit dynamic linking: instead just calling XYZ_whatever, the source code of the app calls OS routines to get pointers to the routines in the dynamic library and then calls using those pointers. For Windows the routines are LoadLibrary or a variant and GetProcAddress; for Unix they are dlopen and dlsym. This is more work, but has the advantage your program can continue if the desired dyn lib or routine is not available, instead of dying. To add to the confusion, implicit and explicit dynlibs are sometimes called static and dynamic, but even a static dynlib is still dynamic as far as execution is concerned. BTW, thanks for the Shining Light Windows build. It's what I am using. Note the Shining Light builds provide all options. If you link with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking. If you link with lib/VC/static/* you get static linking. Or you can code explicitly and use the .dll's directly. In most cases dynamic linking is preferable, usually implicit, and it sounds like for you especially so, but all options work. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Building an exportable OpenSSL application
I have a Windows-only OpenSSL application developed in VS 2010. I have now been tasked with creating parallel regular and exportable (from the US) distributions of the application. I UNDERSTAND YOU CAN'T GIVE LEGAL ADVICE. I'M ONLY LOOKING FOR TECHNICAL INPUT HERE. The application statically links to libeay32XX.lib and ssleay32XX.lib. The application starts out by calling applink(). The distribution includes libeay32.dll and ssleay32.dll. Am I correct in the following premises? - All of the actual encryption algorithms are in libeay32.dll? (And ssleay32.dll?) As I describe my architecture above, my distributed main executable does not contain actual encryption algorithms; they're only in the DLL(s)? - It should be possible to create and distribute a weak encryption only build of libeay32.dll? Personal confession/personal advice time: I have 44 years of experience as a programmer, 40 of it as a successful commercial product developer, but no knowledge of make beyond a grasp of the purpose and concept. (Most of those 44 years are on a platform with no tradition of make; the remainder are exclusively with the MS VS IDE and its predecessors. Make fun of me if you wish.) Question: assuming I am correct that I need to build my own version of libeay32.dll, do you think it's a shorter path to learn make, or to try to do it with MS VS 2010? I am guessing the former. Is there somewhere a ready to roll MS VS project that builds the DLLs? Is there a configure (is that the right term?) option for weak encryption only? I see the no-specific cipher flag but is there a no-strong-ciphers sort of option? I know that SSL_CTX_set_cipher_list() supports the LOW and EXP keywords so OpenSSL must know what are the so-called export ciphers. Would appreciate any additional miscellaneous tips. Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Building an exportable OpenSSL application
On Tue, Oct 16, 2012 at 10:25 AM, Charles Mills charl...@mcn.org wrote: I have a Windows-only OpenSSL application developed in VS 2010. I have now been tasked with creating parallel regular and exportable (from the US) distributions of the application. There's no need for two versions. Its all exportable from the US, except to countries and individuals on the banned list. You can get an exception from the Department of State and export to the banned countries, too (IIRC). In this case, both the Department of Commerce and State Department share joint jurisdiction. You can find more information on the Department of Commerce's website: http://www.bis.doc.gov/encryption/encfaqs6_17_02.html and http://www.bis.doc.gov/encryption/enc_faqs.html. If you want to talk to a live person: US Department of Commerce, Bureau of Industry and Security, Office of Exporter Services, Encryption Division. If you need the phone number and names of the folks in the office, email me offlist. I UNDERSTAND YOU CAN'T GIVE LEGAL ADVICE. I'M ONLY LOOKING FOR TECHNICAL INPUT HERE. This is not legal advice, they are facts of the matter. I've been through the process three times. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Building an exportable OpenSSL application
On 10/16/2012 7:25 AM, Charles Mills wrote: I have a Windows-only OpenSSL application developed in VS 2010. I have now been tasked with creating parallel regular and exportable (from the US) distributions of the application. I UNDERSTAND YOU CAN'T GIVE LEGAL ADVICE. I'M ONLY LOOKING FOR TECHNICAL INPUT HERE. The application statically links to libeay32XX.lib and ssleay32XX.lib. The application starts out by calling applink(). The distribution includes libeay32.dll and ssleay32.dll. If you are linking to OpenSSL DLLs, then your application isn't statically linked against OpenSSL. .lib files can simply be references to exports in .dll files. Am I correct in the following premises? - All of the actual encryption algorithms are in libeay32.dll? (And ssleay32.dll?) As I describe my architecture above, my distributed main executable does not contain actual encryption algorithms; they're only in the DLL(s)? - It should be possible to create and distribute a weak encryption only build of libeay32.dll? Anyone could simply install different binaries and delete yours. Personal confession/personal advice time: I have 44 years of experience as a programmer, 40 of it as a successful commercial product developer, but no knowledge of make beyond a grasp of the purpose and concept. (Most of those 44 years are on a platform with no tradition of make; the remainder are exclusively with the MS VS IDE and its predecessors. Make fun of me if you wish.) Question: assuming I am correct that I need to build my own version of libeay32.dll, do you think it's a shorter path to learn make, or to try to do it with MS VS 2010? I am guessing the former. Is there somewhere a ready to roll MS VS project that builds the DLLs? No there isn't. Well, okay, there is some ancient VS workspace but no one uses it. It is better to follow the README.WIN32 instructions. Is there a configure (is that the right term?) option for weak encryption only? I see the no-specific cipher flag but is there a no-strong-ciphers sort of option? I know that SSL_CTX_set_cipher_list() supports the LOW and EXP keywords so OpenSSL must know what are the so-called export ciphers. A better approach is to dynamically link against OpenSSL and then call that function with the export cipher list in your export build. That way, you can easily replace just the OpenSSL DLLs as new versions come out AND it keeps people from replacing your DLLs with other DLLs and causing unintended side effects. It seems cleaner to me anyway. Would appreciate any additional miscellaneous tips. Charles -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Building an exportable OpenSSL application
If you are linking to OpenSSL DLLs, then your application isn't statically linked against OpenSSL. .lib files can simply be references to exports in .dll files. This is an important point. Can we be absolutely clear? My picture of how this works is that the .lib files contain small stubs so that while the application code has the illusion of making a static call to SSL_whatever() in reality that is a tiny stub that actually calls code in a DLL. There is no functional code in the .lib, only stubs that link to functional code in the DLLS. Am I wrong? This is a critical point. BTW, thanks for the Shining Light Windows build. It's what I am using. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomas J. Hruska Sent: Tuesday, October 16, 2012 8:02 AM To: openssl-users@openssl.org Subject: Re: Building an exportable OpenSSL application On 10/16/2012 7:25 AM, Charles Mills wrote: I have a Windows-only OpenSSL application developed in VS 2010. I have now been tasked with creating parallel regular and exportable (from the US) distributions of the application. I UNDERSTAND YOU CAN'T GIVE LEGAL ADVICE. I'M ONLY LOOKING FOR TECHNICAL INPUT HERE. The application statically links to libeay32XX.lib and ssleay32XX.lib. The application starts out by calling applink(). The distribution includes libeay32.dll and ssleay32.dll. If you are linking to OpenSSL DLLs, then your application isn't statically linked against OpenSSL. .lib files can simply be references to exports in .dll files. Am I correct in the following premises? - All of the actual encryption algorithms are in libeay32.dll? (And ssleay32.dll?) As I describe my architecture above, my distributed main executable does not contain actual encryption algorithms; they're only in the DLL(s)? - It should be possible to create and distribute a weak encryption only build of libeay32.dll? Anyone could simply install different binaries and delete yours. Personal confession/personal advice time: I have 44 years of experience as a programmer, 40 of it as a successful commercial product developer, but no knowledge of make beyond a grasp of the purpose and concept. (Most of those 44 years are on a platform with no tradition of make; the remainder are exclusively with the MS VS IDE and its predecessors. Make fun of me if you wish.) Question: assuming I am correct that I need to build my own version of libeay32.dll, do you think it's a shorter path to learn make, or to try to do it with MS VS 2010? I am guessing the former. Is there somewhere a ready to roll MS VS project that builds the DLLs? No there isn't. Well, okay, there is some ancient VS workspace but no one uses it. It is better to follow the README.WIN32 instructions. Is there a configure (is that the right term?) option for weak encryption only? I see the no-specific cipher flag but is there a no-strong-ciphers sort of option? I know that SSL_CTX_set_cipher_list() supports the LOW and EXP keywords so OpenSSL must know what are the so-called export ciphers. A better approach is to dynamically link against OpenSSL and then call that function with the export cipher list in your export build. That way, you can easily replace just the OpenSSL DLLs as new versions come out AND it keeps people from replacing your DLLs with other DLLs and causing unintended side effects. It seems cleaner to me anyway. Would appreciate any additional miscellaneous tips. Charles -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Building an exportable OpenSSL application
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Tuesday, 16 October, 2012 11:41 If you are linking to OpenSSL DLLs, then your application isn't statically linked against OpenSSL. .lib files can simply be references to exports in .dll files. This is an important point. Can we be absolutely clear? My picture of how this works is that the .lib files contain small stubs so that while the application code has the illusion of making a static call to SSL_whatever() in reality that is a tiny stub that actually calls code in a DLL. There is no functional code in the .lib, only stubs that link to functional code in the DLLS. Am I wrong? This is a critical point. Yes, plus. To be exact, there are really three ways: - traditional (since like 1950) static linking, with .lib on Windows or .a on Unix containing actual code and static data. The linker copies referenced code and data to your Windows .exe or Unix executable. - implicit dynamic linking, with .lib on Windows containing stubs that point to code (and sometimes data, but that's usually poor practice) in a .dll. This type of .lib is called an import library. The linker pulls the stubs into your .exe and and also includes a list of the .dll files; at runtime the OS finds those .dll's using moderately complicated search rules, which can be an issue if you have multiple versions in different places, although in my (limited) experience the simple solution of putting .dll's in the same directory as the .exe always works. On Unix similar but there's no import library; you link directly against .so .sl etc, and the linker puts the imports in the executable. - explicit dynamic linking: instead just calling XYZ_whatever, the source code of the app calls OS routines to get pointers to the routines in the dynamic library and then calls using those pointers. For Windows the routines are LoadLibrary or a variant and GetProcAddress; for Unix they are dlopen and dlsym. This is more work, but has the advantage your program can continue if the desired dyn lib or routine is not available, instead of dying. To add to the confusion, implicit and explicit dynlibs are sometimes called static and dynamic, but even a static dynlib is still dynamic as far as execution is concerned. BTW, thanks for the Shining Light Windows build. It's what I am using. Note the Shining Light builds provide all options. If you link with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking. If you link with lib/VC/static/* you get static linking. Or you can code explicitly and use the .dll's directly. In most cases dynamic linking is preferable, usually implicit, and it sounds like for you especially so, but all options work. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
