Hide Forgot
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.
Can you please open a regular support request in your support channel? This can help properly prioritize the issue. http://www.redhat.com/support/
I don't have a support contract. Your customer, whose name I'll keep out of this public forum, was told that this type of request has to come from the hardware vendor. I work for the hardware vendor (mail Sander.Temme to verify).
I do not quite understand - Red Hat support told your customer that you should do the request? If so, please ask the customer to indicate in his Red Hat support ticket that this bugzilla number should be assigned to his support ticket.
(In reply to comment #3) > I do not quite understand - Red Hat support told your customer that you should > do the request? Yes, that is what I understand has happened. > If so, please ask the customer to indicate in his Red Hat > support ticket that this bugzilla number should be assigned to his support > ticket. We're asking our customer file that support request. Hopefully we can close the loop that way.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1010.html