/usr/lib/ssl/engines subdirectory not packaged

[Sander Temme]

Binary package hint: openssl

When I try to load an Engine usually bundled with OpenSSL, I get the complaint that the shared library containing the engine can't be loaded:

sctemme@surtur:~/projects/ossl-debian/openssl-0.9.8o$ /usr/bin/openssl engine -tt -vvvv -c chil
23449:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(/usr/lib/ssl/engines/libchil.so): /usr/lib/ssl/engines/libchil.so: cannot open shared object file: No such file or directory
23449:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
23449:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450:
23449:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:416:id=chil

When I do the same in an OpenSSL build from source, I can load that Engine:

sctemme@surtur:~/projects/ossl-debian/openssl-0.9.8o$ ~/nCipher/ossl-098r/bin/openssl engine -tt -vvvv -c chil
(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 (non-zero) or off (zero)
          (input flags): NUMERIC
     THREAD_LOCKING: Turns thread-safe locking on (zero) or off (non-zero)
          (input flags): NUMERIC
     SET_USER_INTERFACE: Set the global user interface (internal)
          (input flags): [Internal]
     SET_CALLBACK_DATA: Set the global user interface extra data (internal)
          (input flags): [Internal]

I have previously ensured that the underlying library that this Engine needs is available, but this is not germane to this issue.

sctemme@surtur:~/projects/ossl-debian/openssl-0.9.8o$ ldconfig -p | grep nfast
 libnfhwcrhk.so (libc6,x86-64) => /opt/nfast/toolkits/hwcrhk/libnfhwcrhk.so

The source build has the Engine libraries under its lib/engines directory:

sctemme@surtur:~/projects/ossl-debian/openssl-0.9.8o$ cd ~/nCipher/ossl-098r/
sctemme@surtur:~/nCipher/ossl-098r$ ls -l lib/engines
total 236
-r-xr-xr-x 1 sctemme sctemme 24932 2011-03-24 11:28 lib4758cca.so
-r-xr-xr-x 1 sctemme sctemme 24824 2011-03-24 11:28 libaep.so
-r-xr-xr-x 1 sctemme sctemme 20150 2011-03-24 11:28 libatalla.so
-r-xr-xr-x 1 sctemme sctemme 7762 2011-03-24 11:28 libcapi.so
-r-xr-xr-x 1 sctemme sctemme 31169 2011-03-24 11:28 libchil.so
-r-xr-xr-x 1 sctemme sctemme 29068 2011-03-24 11:28 libcswift.so
-r-xr-xr-x 1 sctemme sctemme 7761 2011-03-24 11:28 libgmp.so
-r-xr-xr-x 1 sctemme sctemme 19509 2011-03-24 11:28 libnuron.so
-r-xr-xr-x 1 sctemme sctemme 31296 2011-03-24 11:28 libsureware.so
-r-xr-xr-x 1 sctemme sctemme 25264 2011-03-24 11:28 libubsec.so

This directory is not present in the libssl package:

sctemme@surtur:~/nCipher/ossl-098r$ dpkg -L libssl0.9.8
/.
/lib
/lib/libcrypto.so.0.9.8
/lib/libssl.so.0.9.8
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libssl0.9.8
/usr/share/doc/libssl0.9.8/copyright
/usr/share/doc/libssl0.9.8/changelog.gz
/usr/share/doc/libssl0.9.8/changelog.Debian.gz
/usr/lib
/usr/lib/libcrypto.so.0.9.8
/usr/lib/libssl.so.0.9.8

When I build the Debian package from source, there is evidence of the Engines being built:

sctemme@surtur:~/projects/ossl-debian/openssl-0.9.8o$ ls -l debian/tmp/usr/lib/engines/
total 464
-rwxr-xr-x 1 sctemme sctemme 55249 2011-04-19 20:14 lib4758cca.so
-rwxr-xr-x 1 sctemme sctemme 51855 2011-04-19 20:14 libaep.so
-rwxr-xr-x 1 sctemme sctemme 41523 2011-04-19 20:14 libatalla.so
-rwxr-xr-x 1 sctemme sctemme 11624 2011-04-19 20:14 libcapi.so
-rwxr-xr-x 1 sctemme sctemme 65943 2011-04-19 20:14 libchil.so
-rwxr-xr-x 1 sctemme sctemme 62245 2011-04-19 20:14 libcswift.so
-rwxr-xr-x 1 sctemme sctemme 11623 2011-04-19 20:14 libgmp.so
-rwxr-xr-x 1 sctemme sctemme 39409 2011-04-19 20:14 libnuron.so
-rwxr-xr-x 1 sctemme sctemme 64985 2011-04-19 20:14 libsureware.so
-rwxr-xr-x 1 sctemme sctemme 52373 2011-04-19 20:14 libubsec.so

Could it be that when the OpenSSL project split out the Engine libraries into separate files, this move was not picked up by the rules file and the Engine libraries not copied into the package?

This is on Maverick x86_64.

[Sander Temme (sander-temme)]

This issue does not appear in Natty Narwhal:

sctemme@surtur:~$ /usr/bin/openssl engine -tt -vvvv -c chil
(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 (non-zero) or off (zero)
          (input flags): NUMERIC
     THREAD_LOCKING: Turns thread-safe locking on (zero) or off (non-zero)
          (input flags): NUMERIC
     SET_USER_INTERFACE: Set the global user interface (internal)
          (input flags): [Internal]
     SET_CALLBACK_DATA: Set the global user interface extra data (internal)
          (input flags): [Internal]

sctemme@surtur:/opt/nfast/toolkits$ dpkg -L libssl0.9.8
/.
/lib
/lib/libcrypto.so.0.9.8
/lib/libssl.so.0.9.8
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libssl0.9.8
/usr/share/doc/libssl0.9.8/copyright
/usr/share/doc/libssl0.9.8/changelog.Debian.gz
/usr/lib
/usr/lib/ssl
/usr/lib/ssl/engines
/usr/lib/ssl/engines/libchil.so <-- There's the one I need!
/usr/lib/ssl/engines/libcswift.so
/usr/lib/ssl/engines/lib4758cca.so
/usr/lib/ssl/engines/libcapi.so
/usr/lib/ssl/engines/libsureware.so
/usr/lib/ssl/engines/libubsec.so
/usr/lib/ssl/engines/libgmp.so
/usr/lib/ssl/engines/libatalla.so
/usr/lib/ssl/engines/libnuron.so
/usr/lib/ssl/engines/libaep.so
/usr/lib/libcrypto.so.0.9.8
/usr/lib/libssl.so.0.9.8

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Maarten Bezemer (veger)]

I checked the Natty package and they are re-added again.
Also, the changelog mentions this:
 openssl (0.9.8o-3) unstable; urgency=high
   * Re-add the engines. They were missing since 0.9.8m-1.