1429692 - Please make algmac.h, blapi.h public and build shared libs of libnssb.a/libnssckfw.a

Status: RESOLVED WONTFIX

(NSS :: Build, defect)

Description

[tjaalton]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171227151206

Steps to reproduce:

Hi, I need these provided by NSS upstream in order to package nss-pem* for Debian, where the maintainer refuses to add the private headers and static libs to the NSS packaging. The other option would be to merge nss-pem in NSS, but AIUI that was already tried earlier..

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732201
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754978
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855879

* https://github.com/kdudka/nss-pem

Comment 1

[Kai Engert (:KaiE:)]

Response from Bob Relyea:

"libfreebl.a is a stub the dynamically loads libfreebl3_priv.so. It's purpose was to handle platforms that had different versions of libfreebl based on the installed hardware (basically sunOS). libfreebl3.so doesn't export those function named, instead exports the function table.

libpem could copy the loader.h, loader.c, and blname.c from libfreebl. That would cause libpem to call freebl dynamically itself."

It seems that your requested change to NSS is wontfix, and the recommendation is that you copy the required code into libpem.

Comment 2

[Kamil Dudka]

Kai, I think you have mixed up two different topics together.  Bob's response was about libfreebl.a whereas this report is about libnssb.a and libnssckfw.a.

Comment 3

[Robert Relyea]

The subject asked for blapi.h and algmac.h to be exported, which aren't use by libnssckfw.a and libnssb.a, they are part of libfreebl.
We aren't likely to produce shared library versions of libnssb.a or libnssckfw.a at this point either.

bob

Comment 4

[Kamil Dudka]

Attachment: ckfw.def

Comment 5

[Kamil Dudka]

We were discussing a possible solution with Bob two days ago.  Bob said that it is impossible to make a shared library out of libnssb.a but it should be possible to make a shared library out of libckfw.a (although nss-pem would be the only external user of it for now).  My homework was to check which symbols from which libraries are actually used by nss-pem.

nss-pem uses NSS_ZAlloc() and NSS_ZFreeIf() from libnssb.a, which seems to be unavoidable because it needs to interchange NSS arena-allocated objects with CKFW.  But I would not care about them too much because the implementation of NSS arenas is not something that receives security updates too often.

As for libnssckfw.a, there were actually not many symbols used directly by nss-pem.  I was able to replace the use of libnssckfw.a in nss-pem by libnssckfw3.so that was exporting just the symbols listed in attachment #8951675 [details].  So a library containing any superset of those symbols should work just fine for the nss-pem use case.

Bob, could you please have a look?

Comment 6

[Robert Relyea]

Comment on attachment 8951675 [details]
ckfw.def

OK, I've I was mistaken. I thought that the framework supplied the C_ calls, but those are created by the nssck.api include file in the module. 

Kamil, was this all that was needed to create the library file (no changes to the make or build system?

NOTE: this will (should) not be used by nssckbi.so.

If you  have working builds, and you include all the patches needed to make them work (and verified that libnssckbi.so does not depend on libckfw.so then I would be happy to approve the patch.

bob

Comment 7

[Kamil Dudka]

Sorry for replying late on this.  The attached file is just a version script that lists the symbols that need to be exported for nss-pem to be able to link ckfw dynamically.  I did not include any changes to the build system because I thought that Mozilla was about to replace the build system completely.

Anyway, making just ckfw a shared library would not solve the policy violation for Debian package maintainers and other distributions do not need it.  So I am not going to spend additional effort on this myself.  I am fine with keeping this bug closed.