Rerelease of OpenSSL v0.9.8r and v1.0.0d for Indy

Hello,

after some weeks of extensive testing I am now releasing updated versions of the above mentioned OpenSSL DLLs. Those libraries are now tested with Windows 2000 up to Windows 7 (x32 and x64 where available). As usual there are no dependencies to any runtime libraries beside the common Kernel/WinSock2 etc.pp.

As I mentioned in the Important Compatibility Announcement two weeks ago I had made a mistake during the compilation of the last two published OpenSSL versions which led to an incompatibility with Windows 2000 and early XP versions. Check the linked post for a list of affected versions.

The issue is now fixed.

Here are the direct links for the updated release for Win32/64:
http://indy.fulgan.com/SSL/openssl-0.9.8r-i386-win32-rev2.zip
http://indy.fulgan.com/SSL/openssl-1.0.0d-i386-win32-rev2.zip
http://indy.fulgan.com/SSL/openssl-0.9.8r-x64_86-win64-rev2.zip
http://indy.fulgan.com/SSL/openssl-1.0.0d-x64_86-win64-rev2.zip

I am sorry for the inconvenience caused and I would like to thank Jason Smith again for bringing this issue to my attention and Salvor Hardin for his help!

As Salvor stated in one of his comments using Visual C++ 2008 with an adjusted makefile works (the /MT switch as mentioned in the previous post). We should keep in mind that this way of building the DLLs may not work in future but for now and the next few years it should do the trick. To make it short – @Savlor: You were right!

Cheers,
Arvid

Advertisements

9 thoughts on “Rerelease of OpenSSL v0.9.8r and v1.0.0d for Indy

  1. IMHO supporting unsupported Windows version is a waste of time. Those using those releases are already using unsecure systems. Support for Windows 2000 ended July 13th, 2010. XP without service pack support should have ended as well. What’s the difference having an up-to-date OpenSSL support if other well known vulnerabilities are present? It’s like securing some doors while the windows (ops!) are open…

  2. Pingback: Indy용 OpenSSL DLL 업데이트. | Venus Debris' Blog

  3. I disagree with you LDS. Not every PC has to be up to date. Especially if you are not using it online or have it secured by an other PC or firewall.

    In fact I am very thankful that arvid made this and build these dlls who are not relying on some other components installed.

    Thank you for the work you put in it.

  4. @LDS: I know, but as long as it’s possible we try to keep it supported. Main focus is of course on the officially supported OSs but there are still some users wanting to support those deprecated systems.

    @GSA: Thank you very much for your kind words!

    Cheers,
    Arvid

    • Hi Doug,

      can you please clarify what you mean by “a static version of the non-crt runtime”? There is no such thing as a non-crt runtime used here, it’s just that I adjusted the options to use /MT (instead of /MD). Nowadays VC usually links against MSVCR***.dll as you know, this is avoided by using /MT.

      The tricky part is to know when it’s safe as you rely on kernel and msvcrt.dll imports without linking against them. So if you use some features as exported by newer MSVCRT runtimes you will likely see failing dlls when those subset is not supported by user’s system.

      But speaking for OpenSSL it is safe – I check the imports manually with each and every build.

      Cheers,
      Arvid

      P.S.: Sorry for the very, very late reply.

  5. Sorry if this is the wrong thread to ask but this pages was googled.
    I have tried the 64 zip file in Delphi XE2 and tried to compile 64bit code.

    All compiles aok but the SSL dlls cant be loaded. Is there anyone who has tried this yet? Can someone point me in the right direction please.

    Regards
    Craig

    • Hi Craig,

      I tested my 64-bit DLLs with XE2 some time ago and they work fine with a x64 VCL application. I’ll have a look at it today and create a post if I find any problems.

      Regards,
      Arvid

      • Update: Tested again under Win 7 x64 with XE2 using my x64 dlls (openssl-1.0.0d-x64_86-win64-rev2). As expected it’s working absolutely fine.

        Craig – Have a look using a Sniffer like Wireshark to see what’s going on.

        Regards,
        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