On 4/16/21 11:12 AM, Thomas Klausner wrote:
Hi Ryan!
Thanks for the reply.
Bob's reply was quite helpful already with his hint that nothing
should link against softokn3 or freebl. This was a bug in pkgsrc
previously, but I fixed it after his message. Nothing in pkgsrc now
links against either of the two directly. I think I followed all of
his advice.
nss seems to take great care to be interoperable with openssl. But I
still don't understand how this works in detail. Perhaps you can shed
some more light on this to help me debug this problem.
Bob wrote that NSS hides the conflicting symbols through a dynamically
loaded object and a function table. I assume this means using
dlopen(). I'm not sure about the function table.
NSS hides the symbols with shared libraries that only export a curated
set of public symbols. Each nss shared library has it's own symbol list
found in {sharedlibname}.def so lib/nss/nss.def lib/util/nssutil.def
lib/ssl/ssl.def etc.
The NSS build system massages this file to whatever system the OS uses
to create an use an explicit export list for your shared library.
When you link with NSS, you need to link with the NSS shared library,
namley libnss3.so libnssutil3.so libssl3.so and libsmime3.so (depending
on how much of NSS you need). libsoftken3 will be automatically loaded
by libnss3.so and it in term will automatically load libfreebl* as
needed. So only the last two are dlopened. You should not link with any
libnss*.a files, or all bets are off on working with something like openssl.
If you are doing all this and still running into issues, it's likely the
build system (either your own or the NSS build system) isn't correctly
processing the .def file for your platform. The command to process the
.def file is set with the symbol PROCESS_MAP_FILE and is set in your
{OS}.mk file in nss/coreconf.
Linux, for instance, sets the command as follows:
PROCESS_MAP_FILE = grep -v ';-' $< | \
sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,' > $@
This removes all the lines with ;- , then removes all occurrences of
';+',' DATA ',';;', and then all commands '; to the end of the line'
Linux later adds the directive -Wl,-c,$(MAPFILE) to it's shared library
linking command.
It looks like openBSD has the same processing line as linux, and adds
-Wl,--version-script,$(MAPFILE) which sounds right to me.
(Some unsupported OSs ignore the MAPFILE, and they could be subject to
symbol collisions).
bob
I looked at the code a bit and see that HASH_Update calls a function
indirectly, which in pk11cxt.c is forwarded and finally used in
pkcs11c.c - which however, then uses the wrong function, the one from
openssl.
Can you please explain in more detail how the function table works?
In my case, it seems the wrong MD5_Update function is used when
openssl is linked into the binary.
Perhaps it's a difference in linker behavior on NetBSD?
As for pkgsrc - I cited the patches in my original email. The whole
package information is [1], the Makefile contains the flags used when
compiling and the patches directory the patches used. If you see what
the problem is, that'd be very helpful, but I don't think it's
something that's something obvious any longer.
[1] https://github.com/NetBSD/pkgsrc/tree/trunk/devel/nss
Thanks,
Thomas
--
You received this message because you are subscribed to the Google Groups
"dev-tech-crypto@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-tech-crypto+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/8c271011-93c3-529f-6e08-deff68d9bb32%40redhat.com.
