Bug 671484

Description of problem:

The CHIL Engine, used to access Thales/nCipher hardware, requires that thread locking upcalls be set regardless of whether the calling program is multithreaded.  This is discussed in the following OpenSSL ticket:

http://rt.openssl.org/Ticket/Display.html?id=1736

This issue was caused to go away in the following OpenSSL commit: 

http://cvs.openssl.org/filediff?f=openssl/engines/e_chil.c&v1=1.1.2.5&v2=1.1.2.6

which was part of 0.9.8j.  

Version-Release number of selected component (if applicable):

Any OpenSSL before 0.9.8j is affected. Any Red Hat Enterprise Linux 5 release is affected.  Tests conducted with OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, and openssl-0.9.8e-12.el5_5.7 on RHEL 5.5. 

How reproducible:

Attempt to load the CHIL engine into the Red Hat supplied copy of OpenSSL.

Steps to Reproduce:
1. Install nCipher hardware.
2. Install nCipher software.
3. Set and export LD_LIBRARY_PATH=/opt/nfast/toolkits/hwcrhk
4. Call /usr/bin/openssl engine -vvvv -tt -c chil
  
Actual results:

(chil) CHIL hardware engine support
[RSA, DH, RAND]
     [ unavailable ]
13205:error:80067072:CHIL engine:HWCRHK_INIT:locking missing:e_chil.c:594:You HAVE to add dynamic locking callbacks via CRYPTO_set_dynlock_{create,lock,destroy}_callback()
     SO_PATH: Specifies the path to the 'hwcrhk' shared library
          (input flags): STRING
     FORK_CHECK: Turns fork() checking on or off (boolean)
          (input flags): NUMERIC
     THREAD_LOCKING: Turns thread-safe locking on or off (boolean)
         (input flags): NUMERIC

Expected results:

(chil) CHIL hardware engine support
[RSA, DH, RAND]
     [ available ]
     SO_PATH: Specifies the path to the 'hwcrhk' shared library
          (input flags): STRING
     FORK_CHECK: Turns fork() checking on or off (boolean)
          (input flags): NUMERIC
     THREAD_LOCKING: Turns thread-safe locking on or off (boolean)
         (input flags): NUMERIC

Additional info:

If a multithreaded program calls OpenSSL and loads the CHIL Engine without setting those callbacks, unexpected behavior may occur.  It is my opinion that in this case, you get what you deserve.  

Apache 2.2 was updated to set the right upcalls in the same timeframe the OpenSSL RT issue was discussed, and this fix was already backported by Red Hat.