Comment 1 for bug 1744328

From IRC discussion:
[13:20] <cpaelzer> xnox: hey I'd need your help/guidance on libnss that you touched recently
[13:20] <cpaelzer> it has headers like /usr/include/nss/hasht.h which are backed by a .so in a subdir /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
[13:20] <cpaelzer> those are usually not meant to be direct includes, but it has symbols for it and everything
[13:21] <cpaelzer> it currently breaks the change of a lib usage that is not in main to use nss for this instead
[13:21] <cpaelzer> so I wonder if that lib should maybe not be in the subpath, but actually directly in /usr/lib/x86_64-linux-gnu/
[13:22] <cpaelzer> xnox: slangasek pointed out that you touched it recently, so we had some hope you might have a hint on this
[13:22] <cpaelzer> as it seems not really to be ment for dlopen only (symbols/headers available "normally")
[13:23] <cpaelzer> I'm on sprint, so latency to reply is high, but it would be great to hear your insight on this
[13:24] <xnox> cpaelzer, i will look into it. It does seem odd.... unless like libnss.so itself knows how to dlopen extra things.
[13:24] <xnox> can't recall anything special around it, off the top of my head.
[13:27] <cpaelzer> xnox: thanks for taking a look
[13:28] <cpaelzer> xnox: if it is meant to be internal only ok, but if not making it properly public would be great
[14:55] <xnox> cpaelzer, i am failing to understand what it is; but on e.g. Fedora, they have a separate source package nss-softokn which does have binary packages nss-softokn-freebl[-devel] which does ship those libs as normal public libraries; they also have some dracut snippets to include those into initramfs....
[14:55] <xnox> they have .chk files and can be used in FIPS mode
[14:55] <xnox> not sure about /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so what that one is yet, as it does not appear to be anywhere.
[14:57] <xnox> oh maybe that one is in the base nss package, one sec.

I'll loose connection soon, so lets continue in this bug to not loose it