[lsb-discuss] NSS: soname problems and compatibility issues

Robert Relyea rrelyea at redhat.com
Wed Aug 27 10:48:31 PDT 2008


Robert Relyea wrote:
>
> Jeff Licquia wrote:
>> It's been discussed in IRC, but probably should be discussed a little 
>> more formally.
>>
>> The proposed NSS spec uses libnss3.so and libssl3.so as the library 
>> filenames.  But some poking around by a few people revealed that not 
>> all distros provided this file.
>>
>> (Additionally, there was a claim on a mailing list that some sonames 
>> were changed because of incompatibility issues.  But we seem to have 
>> lost that reference.)
>>   
> There shouldn't be any compatibility issues. Any that arise are p1 
> bugs for NSS upstream. We specifically design new versions to slide in 
> under old versions so older apps can always user a newer version of NSS.
I should add that one concern debian had was to make sure applications 
which were compiled with newer versions of NSS would not have 
compatibility problems when installed on systems with older versions of 
NSS installed.

NSS uses the built in linux SO versioning scheme for this.

There was once a case we (Red Hat) ran into with the browser. A browser 
was rebuilt using a newer version of NSS and installed. That browser did 
not work on a system with an older copy of NSS. This was caused by 2 things:

1) The browser linked with a static NSS library to do crmf (mozilla 
products are the only products I know of that uses this static library).
2) That static library was updated to use a new API exposed in the new 
version of NSS.
3) The mozilla package build (at least the RH rpm) was stripping out the 
Linux library versioning information that tells the package what version 
of the library to use.

NSS uses .def files to control exports of symbols. Each symbol is tagged 
with the release of NSS that it was first exported. This is to prevent 
the compatibility issue above, however the application in question 
stripped that information. The correct fix is not to strip that 
information (which is implemented in the RH systems now).

I don't know if debian ran into a similar issue since no one reported 
any compatibility issues to the NSS team.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080827/694eaa63/attachment.bin 


More information about the lsb-discuss mailing list