Important Compatibility Announcement regarding OpenSSL

The latest two versions of OpenSSL I’ve released only support Windows XP SP2, Windows Server 2003 SP1 and newer.

The affected OpenSSL versions are:
0.9.8 q, 0.9.8 r, 1.0.0 c and 1.0.0 d.

Technical Background:

The mentioned libraries statically link against a version of msvcrt.lib which include references to EncodePointer/DecodePointer and _except_handler4_common. EncodePointer and DecodePointer are only available with the aforementioned OS versions. The CRT exception handler 4 has been introduced with newer versions of msvcrt.dll too (XP iirc).

Since mid 2010 I used a different approach in building the libraries, instead of my old-fashined mingw gcc 3.4.5 build chain Salvor came up with the idea to use VC++ with special adjustments as posted in his comment here.

Typically DLLs created with VC newer than 6 have dependencies to the corresponding runtime libraries (the well-known msvcrt##.dll). Using his approach removed this dependencies. My initial tests with XP, 2003, Vista and Win 7 didn’t show any problems, Dependency Walker had not shown problems too. But as it turns out now Salvor didn’t take the changed feature set of msvcrt.dll into account. And I didn’t do either.

I spend a large amount of time within the past two weeks to test all available build chains possible, including VC 2008 and 2010 together with masm and nasm, mingw with gcc 3.4.5 up to gcc 4.5.2 and today even the Windows Device Driver Kit 7.1 together with PSDK 2003 and SDK for Win 7 and .NET 4. Using the DDK was an interesting approach to circumvent the mentioned problems (Thanks to Mladen Turk for his interesting post titled Fighting the MSVCRT.DLL hell), but fails with the exception handler 4 too.

I am aware of the stubs published at StackOverflow regarding this issue with Encode/DecodePointer, but believe me that’s nothing we want in productive code.

Currently the only two working alternatives are:

  • gcc 3.4.5
  • VC++ 6

As we switched away from gcc 3.4.5 for several reasons (size and performance of the created libraries) I would prefer using VC++ 6.0. The OpenSSL build chain for gcc 4 is broken like the BCB chain is for years now. I cannot afford spending so much time on fixing the perl scripts with every OpenSSL release. Currently I publish four sets of files with every OpenSSL release (0.9.8.x for x32 and x64, 1.0.0.x for x32 and x64) and create 2 additional ones for internal FIPS 140 tests. Together with testing the libraries and the preps needed for publishing this became a lot of work compared to the past years.

Why don’t you just use other precompiled binaries?

I know what you’re talking about. The precompiled libraries other vendors like Shining Light publish do require the MS VC runtime dlls. We want to give the Indy the possibility to ship OpenSSL without any VCRT dlls. Afaik the newer VCRT requires that you include the official MSI packages. This has many drawbacks.

What do you need to do now?

Please check if you use any of the above mentioned Indy OpenSSL libraries in a productive environment together with an OS older than the supported ones. If that may be true I would suggest updating your release information, platform requirements or inform your users / customers where needed.

This is only required if you use our libraries (as published on the Fulgan mirror).

Note the reverting back to an older version of OpenSSL is not an option due to well-known security issues as published on the OpenSSL site or US CERT.

What can you do to help?

I would like to ask for a donation of a single copy license of MS VC++ 6 or MS Visual Studio 6 (English). This would help tremendously with the effort to keep the old OSs like Win 2000 supported way beyond what MS does on it’s own. We have a bunch of licenses, tools and compilers available here at the office but nothing that old as the ancient VC 6 😉

So, if anybody is willing to help the Indy team (and me) drop a mail to winkelsdorf [at] gmail [dot] com.

Thanks to Jason Smith for bringing up this issue to the Indy team at the Atozed Newsgroup!

Cheers,
Arvid

[Edit2]
Removed my rant about those DelphiFeeds Off-Topic Voters 😉
[/Edit2]

Advertisements

6 thoughts on “Important Compatibility Announcement regarding OpenSSL

  1. Hi,

    I looked into this a while back.

    Visual C++ 2008 creates binaries that run in Windows 2000.

    Visual C++ 2010 creates binaries that don’t support Windows 2000. It is possible to hack binaries to workaround this, but not recommended.

    So you don’t need Visual C++ 6. In fact, VC6 might not be able to compile newer versions of OpenSSL.

  2. @Savlor: I retested each and every possible combination. Visual C++ 2008 did the trick together with the /MT switch – at least for Win32, for Win64 I used PSDK 2003 SP1 (newer versions have the same problem again). Having a look at the created DLLs they differ from what I would call standard dlls because of the missing imports from msvcrt.dll but anyway they work even with Win2000.

    I am now going to post about the new release. Thank you for the comments.

    And last but not least: Yes, Visual C++ 2005 would be a great help too.

    Cheers,
    Arvid

  3. Pingback: Arvid’s Blog @ digivendo » Rerelease of OpenSSL v0.9.8r and v1.0.0d for Indy

  4. IMHO one of the major problems OpenSSL developers introduce was the usage of static (MSV)CRT linkage. When building library version of ssl libraries I always have to patch the make files and use the /MD option. Using this we are able to create .dll’s that have both ssl library versions and msvcrt.dll linkage. So far using this approach (and DDK for building) we have produced numerous Apache Tomcat Native official binaries (not to mention my daily work at Red Hat)

    • Mladen –
      thanks for your comment! I agree, I use the same approach patching the make files in my automated build process for exactly the same reasons.
      Cheers,
      Arvid

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s