Bug 429846

Summary:	openssl: SHLIB_VERSION_NUMBER != soname ?
Product:	[Fedora] Fedora	Reporter:	Rex Dieter <rdieter>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	openssl-0.9.8g-4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-01-26 20:40:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	440403, 440404, 440406

Description Rex Dieter 2008-01-23 13:16:05 UTC

Due to licensing issues, kdelibs dlopens openssl instead of linking.  In order
to make this work, kdelibs needs to know the soname of both libcrypto and
libssl.  Upstream kdelibs *tries* to use libssl.so.SHLIB_VERSION_NUMBER (and
libcrypto.so.SHLIB_VERSION_NUMBER) as defined by openssl/opensslv.h header. 
Unfortunately, this doesn't work, since
SHLIB_VERSION_NUMBER=0.9.8
and the soname in rawhide is named
libssl.so.0.9.8g

In order to workaround this, we're currently having to patch kdelibs to hardcode
looking for libssl.so.0.9.8g/libssl.so.7

Is the value of SHLIB_VERSION_NUMBER incorrect?
Is this usage/expection of SHLIB_VERSION_NUMBER to name sonames invalid?
Any suggestions on how to make this work better?

Comment 1 Tomas Mraz 2008-01-23 14:07:18 UTC

The file name in rawhide has to be ....0.9.8g otherwise it would conflict with
potential compat libraries with different SONAME.

We should probably patch the SHLIB_VERSION_NUMBER to reflect that but it could
theoretically break other things as I don't know how 3rd party apps use this macro.

But don't ask me what I think about dlopening openssl libraries to overcome the
GPL incompatibility.

So this will not be a priority for me to solve. kdelibs should instead use GPL
or GPL compatible licensed code for SSL. Such as nss_compat_ossl library.

Comment 2 Rex Dieter 2008-01-23 14:11:42 UTC

Interested in exposing SHLIB_SONAMEVER (in opensslv.h or somewhere) as 
referenced in openssl-0.9.8g-soversion.patch ?

That could serve nicely.

Comment 3 Tomas Mraz 2008-01-23 15:13:36 UTC

I could add that but will it really help you? It will not be in openssl upstream
so KDE cannot depend on it.

Comment 4 Rex Dieter 2008-01-23 15:24:29 UTC

fair nuf, I'll try pinging both openssl, kde upstreams and see how best to
address this.

Comment 5 Rex Dieter 2008-01-23 16:21:34 UTC

fyi, http://marc.info/?l=openssl-users&m=120110500517612&w=2

Comment 6 Tomas Mraz 2008-01-23 22:51:41 UTC

The soname is actually libssl.so.7 - we patch it to be so otherwise it would be
libssl.so.0
- we do this because the abi is not stable so we almost always have to bump
sonames on version upgrades

The file name is libssl.so.0.9.8g - again we patch it this way otherwise it
would be libssl.so.0.9.8
- again we do this so multiple openssl versions (with potentially different ABI)
could be installed together.

This makes us (not upstream) to be not in sync with SHLIB_SONAMEVER. So this
question doesn't make much sense to be reported upstream. As I wrote we
could/should probably patch the SHLIB_SONAMEVER to be 0.9.8g but there is a
small possibility it might break things.

Comment 7 Rex Dieter 2008-01-24 03:04:48 UTC

Thanks for the clarification. 

I don't care so much about SHLIB_SONAMEVER, it's the value of
SHLIB_VERSION_NUMBER that I'm more interested in, since that is what (upstream)
kdelibs uses to determine the name of the shlib(s) to dlopen.

Comment 8 Rex Dieter 2008-01-24 03:08:03 UTC

My take/wish: fix SHLIB_VERSION_NUMBER to match reality.  3rd-parties that use
this are broken in the status-quo (e.g. kdelibs).

Comment 9 Tomas Mraz 2008-01-24 08:02:46 UTC

(In reply to comment #7) 
> I don't care so much about SHLIB_SONAMEVER, it's the value of
> SHLIB_VERSION_NUMBER that I'm more interested in, since that is what (upstream)
> kdelibs uses to determine the name of the shlib(s) to dlopen.

Oops, I meant SHLIB_VERSION_NUMBER instead of SHLIB_SONAMEVER in the comment 6.

Comment 10 Tomas Mraz 2008-01-26 20:40:54 UTC

Fixed, let's see what breaks - if anything.