Search
j0ke.net Open Build Service
>
Projects
>
home:netmax
:
monitoring
>
openssl1
> README.SUSE
Sign Up
|
Log In
Username
Password
Cancel
Overview
Repositories
Revisions
Requests
Users
Advanced
Attributes
Meta
File README.SUSE of Package openssl1
1. Building with libopenssl1 - libopenssl1_0_0 can be installed parallel to the system libopenssl0_9_8. - libopenssl1-devel is as development package in conflict with the libopenssl-devel of 0.9.8j, so only one of it can be installed. If you want to build against libopenssl1 deinstall the libopenssl-devel package and install the libopenssl1-devel package. The conflict is necessary as the header and .so files are in the same locations. - The "openssl1" package contains the commandline tool renamed to "openssl1". It can be used for debugging. In the system it is used to correctly hash the root certificates in /etc/ssl/certs in "openssl 1" style. - The openssl1-doc package contains the openssl1 developer documentation and so conflicts with openssl-doc with similar content. - The "openssl-certs" package was extended to generate both openssl 0.9.8j and 1.0.1 compatible hashes for root certificates. (The root certificates are needed to SSL clients to validate remote hosts.) The openssl1 package contains the "c_rehash1" binary equivalent to the "c_rehash" binary. "c_rehash1" is able to generate both type of signatures. 2. Shadow Libraries Some libraries link against libcrypto.so.0 or libssl.so.0 which would then cause both libcrypto.so.0 and libcrypto.so.1 (and libssl.so.0/1) loaded in the same process. As both the 0 and 1 major versions use the sanme function names but a different API, this will likely trigger crashes or other misbehaviour. So it needs to be ensured that the final program only loads libcrypto.so.1 and libssl.so.1, but not the .0 versions. For this reason we offer some shadow libraries that are built on the exact same source level as the regular libraries, but against the openssl 1 version. As these offer the same APIs to users, other changes should not be necessary. These libraries live below /opt/suse/lib64 (for 64bit systems) and /opt/suse/lib (for 32bit systems) and are reachable either during build time (RPATH) or during runtime (LD_LIBRARY_PATH environment variable). We currently include the following packages containing shadow library RPMs: libldap-openssl1-2_4-2 cyrus-sasl-openssl1 libcurl4-openssl1 And some SASL Plugins in the shadow library area: cyrus-sasl-openssl1-plain cyrus-sasl-openssl1-gssapi cyrus-sasl-openssl1-digestmd5 For building your libraries and binaries, please add the linker flag on 64bit systems: -Wl,-rpath,/opt/suse/lib64 or on 32bit systems: -Wl,-rpath,/opt/suse/lib This makes the application and library look for the libraries in the shadow location first, and in the regular system locations later. If a library or application has been correctly built this way, can be checked using: "readelf -a app|grep RUNPATH". A good result would look like this: readelf -a /usr/lib/postfix/smtp|grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/opt/suse/lib64] If all shadow libraries are correctly in use can be found out using "ldd", e.g. with postfix: ldd /usr/lib/postfix/smtp|grep /libssl.so.0 ldd /usr/lib/postfix/smtp|grep /libcrypto.so.0 ... This should result in no hits. Please make sure you build both your libraries and binaries using the rpath flags, as the rpath lookup is not transitive. If you are missing shadow libraries, please contact SUSE support.
